Interfaces Java, implémentation et compatibilité

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?

Salut,

Citation:

---

Envoyé par zaxx70

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.

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.

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:

---

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++

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:

---

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...

Citation:

---

Envoyé par 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:

---

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:

---

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.

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


a++

Citation:

---

Envoyé par adiGuba

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


a++

---

Un pool de connexions. J'ai une classe PoolableConnection qui implémente Connection, puis un ConnectionPool qui gère des PoolableConnection et renvoie une Connection par une méthode getConnection. Le problème est l'utilisation de ce pool dans des modules sur lesquels je n'ai pas la main. Il me faudrait pouvoir faire fonctionner PoolableConnection en 1.5 et 1.6 de façon transparente pour les modules finaux.

Si tu compiles en 1.6 avec l'option -target 1.5 ca devrait passer.

En 1.5 tu aurais ces méthodes supplémentaires, mais cela ne devrait pas poser de problème tant qu'elles ne sont pas appelées (ce qui ne devrait pas être le cas).



Si tu n'a qu'à gérer la méthode close(), une autre solution serait peut-être de passer par un Proxy...

a++