Discussion :

[zaxx70]

Bonjour,

Voici une question concernant un problème de compatibilité Java que je rencontre sur l'un des projets sur lequel je travaille.

Ce projet, comportant un nombre important de modules et de classes, était compilé jusque récemment avec Java 5. Une des classes développées implémente une interface de base (java.xxx) de la librairie runtime possédant une méthode.

En passant en Java 6, le projet ne compile plus car l'interface de base expose maintenant deux méthodes.

Ma première solution était d'implémenter la seconde méthode avec un squelette vide, mais dans ce cas, le projet ne compile plus en Java 5, car cette méthode référence des classes qui n'existent pas en Java 5.

Le serpent se mord donc la queue...

Une solution simple était de transformer la classe pour ne plus implémenter l'interface (et donc de ne pas avoir à implémenter la méthode inutile), malheureusement cela est irréalisable, car de nombreux appels dans le code du projet utilisent l'interface et pas la classe et cela demanderait un temps considérable à modifier.

Est-il possible par exemple d'effectuer une compilation sélective en fonction de la version de Java comme on le ferait en C avec des #define?

[adiGuba]

Salut,

En passant en Java 6, le projet ne compile plus car l'interface de base expose maintenant deux méthodes.

Quel est l'interface en question ?
Parce que normalement les interfaces n'évoluent pas entre deux versions de Java, justement pour éviter ce genre de problème.


a++

PS : Sauf à partir de Java 8 qui mettra en place les méthodes par défaut pour pallier à cette contrainte.

[thelvin]

Probablement javax.sql.DataSource qui, depuis 1.6, étend désormais la nouvelle interface java.sql.Wrapper qui introduit deux nouvelles méthodes.
J'ai eu le problème une fois, ça m'a surpris.

Pendant la transition 1.5 vers 1.6, j'ai réglé le problème à coup d'introspection : si la fonctionnalité n'est pas trouvée par introspection, on est en 1.5 et la méthode renvoie UnsupportedOperationException (elle ne sera pas appelée de toute façon puisqu'on n'étend pas Wrapper.) Si on la trouve, on s'en sert.

À noter qu'on peut aussi juste avoir l'approche "non, je ne suis un wrapper de rien." C'est suboptimal mais ça change rien au fonctionnel.

[adiGuba]

En effet...

Mais en théorie ce devrait être au driver JDBC de te fournir le DataSource en question.


Maintenant, je ne vois pas en quoi il ne serait pas possible d'implémenter ces méthode quand même en Java 5, du moment qu'on n'utilise pas l'annotation @Override) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class MyDataSource implements DataSource {
 
	// @Override
	public boolean isWrapperFor(Class<?> iface) throws SQLException {
		return false;
	}
 
	// @Override
	public <T> T unwrap(Class<T> iface) throws SQLException {
		throw new UnsupportedOperationException("unwrap");
	}
 
	@Override
	public Connection getConnection() throws SQLException {
		// TODO
	}
 
	...
}

a++

[zaxx70]

En effet...

Mais en théorie ce devrait être au driver JDBC de te fournir le DataSource en question.


Maintenant, je ne vois pas en quoi il ne serait pas possible d'implémenter ces méthode quand même en Java 5, du moment qu'on n'utilise pas l'annotation @Override) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class MyDataSource implements DataSource {
 
	// @Override
	public boolean isWrapperFor(Class<?> iface) throws SQLException {
		return false;
	}
 
	// @Override
	public <T> T unwrap(Class<T> iface) throws SQLException {
		throw new UnsupportedOperationException("unwrap");
	}
 
	@Override
	public Connection getConnection() throws SQLException {
		// TODO
	}
 
	...
}

a++

En fait il ne s'agit pas de DataSource, mais de Connection. Cependant, le problème est similaire. En 1.6, Connection étend Wrapper, donc il faut ajouter les deux méthodes, ce qui ne pose pas de problème. Le problème vient des méthodes s'appuyant sur des classes inexistantes en 1.5:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
NClob createNClob() throws SQLException;
 
SQLXML createSQLXML() throws SQLException;
 
void setClientInfo(String name, String value) throws SQLClientInfoException;
 
...

Quoi que je fasse, le compilateur se plaint de ne pas trouver NClob, SQLXML et SQLClientInfoException.

[adiGuba]

Pourquoi tu as besoin d'implémenter java.sql.Connection ?
Tu développes un driver JDBC ?


a++

[devyreham]

Une façon violente:
- masquer l'Interface Java6 avec ta propre Interface.
- la mettre dans un module (meme tout seul)
- faire une refactorisation massif des imports/noms par ton interface personnalisé.
- Enfin, si tu utilises Maven, faire une dépendence sur ce module pour la version Java6

Tu refais la meme "manip" avec une Interface du meme nom mais compatible Java5.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
/*module Java6*/
public interface B extends A5
 
/*module Java5*/
public interface B extend A6
 
/*les autres modules ne voient que B au lieu de A5*/
import x.x.B
public class C implements B

de toute façon tu devras faire 2 tâches de compilations différentes.

Edit: suppression des anglicismes...