Interface et JDK multiple.

Version imprimable

09/02/2006, 10h23
moritan

Interface et JDK multiple.

Bonjour,

Voila mon problème.
J'ai un programme basé sur une JDK 1.3 qui doit maintenant aussi tourné sur une JDK1.4,
tout va bien pour 99% du code sauf pour une classe qui inplémente Connexion.

Et oui en 1.4 il manque des méthodes et en 1.3 ces méthodes n'existe pas

Quelqu'un a-t-il une idée pour contourner le problème?
Le but étant de ne garder si possible qu'une seule appli pour facileter la maintenance.
Pour info on sait déterminer sur quel plateforme on tourne
09/02/2006, 10h47
Stane

Re: Interface et JDK multiple.

Citation:

Envoyé par moritan

Et oui en 1.4 il manque des méthodes et en 1.3 ces méthodes n'existe pas

???
09/02/2006, 10h52
Gfx

Citation:

Et oui en 1.4 il manque des méthodes et en 1.3 ces méthodes n'existe pas

Heu elles n'existent ni dans 1.4 ni dans 1.3... ? Tu peux etre un peu plus clair voire carrement nous montrer du code source ?

Ca me parait tres etrange car jamais Sun n'enleve des methodes de l'API publique.
09/02/2006, 11h04
moritan
Désolé effectivement en me relisant, je ne suis pas très clair, voir limite opaque... :roll:

Ce que je voulais dire c'est que pour faire tourner mon code sur une JDK1.4 l'interface connexion m'oblige à implémenter de nouvelles méthodes comme par exemple:
Code:

1 2 3 public void releaseSavepoint(Savepoint arg0) throws SQLException { conn.releaseSavepoint(arg0); }
Le problème c'est que ces méthodes ne compilent pas en 1.3(logique).

Et donc comme ces méthodes supplémentaires ne sont pas utilisés dans mon code, est-il possible de compiler tout le temps mon code (sans les méthodes inutiles) en 1.3 et de le faire tourner sur une plateforme 1.4 ?
Ou le fait que certaines méthodes soit absentes risque de parasité le JDK 1.4.?
09/02/2006, 11h15
Gfx

Tu peux utiliser la reflection pour que ca compile sur un JDK 1.3. Le mieux est de toujours compiler avec 1.4. Si ces methodes ne sont jamais invoquees par un JDK 1.3, cela ne posera pas de probleme... tant que tu ne compiles pas :)
09/02/2006, 11h25
adiGuba

Salut,

Petite question : tu parles bien de l'interface java.sql.Connection c'est ca ?

Est-ce que tu écris un driver JDBC ? Parce que sinon il n'y a pas vraiment d'intérêt à implémenter cette interface...

a++
09/02/2006, 11h48
moritan

Non je n'écris pas de driver JDBC.

En fait on utilise cette nouvelle classe pour stocker les preparstatements, et les retrouver plus facilement.
De plus comme on passe par un pool de conexion, on à redéfini la méthode close afin de fermet tout les statements ouvert sur cette connexion et de libérer la connexion pour le pool.

Comme ça c'est transparent lors du dev.

C'est peut-être pas la meilleur option mais il serait difficile de revenir en arrière maintenant.

Une solution :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
public class TestConn implements Connection
{
 
    private static Method     mReleaseSavepoint     = null;
    private Connection conn                         = null;
 
    /**
     * Check Connection compatibility
     */
    static 
    {
        try
        {
            mReleaseSavepoint = Connection.class.getDeclaredMethod("releaseSavepoint",new Class[]{Savepoint.class});
        }
        catch(Exception ex)
        {
            mReleaseSavepoint = null;
        }
    }
 
    /**
     * 
     * @param conn
     */
    public TestConn(Connection conn)
    {
        this.conn = conn;
    }
 
    public void releaseSavepoint(Savepoint arg0) throws SQLException 
    { 
        if ( mReleaseSavepoint == null )
        {
            throw new NoSuchMethodError("Not implemented in jre < 1.4");
        }
        try
        {
            mReleaseSavepoint.invoke(conn, new Object[]{arg0});
        }
        catch(IllegalArgumentException ex)
        {
            throw new SQLException(ex.getMessage());
        }
        catch(InvocationTargetException ex)
        {
            throw new SQLException(ex.getMessage());
        }
        catch(IllegalAccessException ex)
        {
            throw new SQLException(ex.getMessage());
        }
    }
 
 
    /** 
     * @see java.sql.Connection#createStatement()
     * @return
     * @throws java.sql.SQLException
     */
    public Statement createStatement() throws SQLException
    {
        return conn.createStatement();
    }
 
    // ....

09/02/2006, 13h47
Glob

Citation:

Envoyé par Gfx

Ca me parait tres etrange car jamais Sun n'enleve des methodes de l'API publique.

Mmhh... c'est un autre sujet, mais quand certaines méthodes sont deprecated depuis bientôt 60'000(*) ans, y'aurait quand même moyen de...

Enfin bref, compatibilité quand tu nous tiens :mrgreen:

(*) voire plus pour certaines

Autre solution, si ton code est prévu pour fonctionner sur un JDK 1.3 ou supérieur, tu peux utiliser un Proxy (apparut dans le JDK 1.3). L'avantage c'est que tu n'as pas besoin de redéfinir toutes les méthodes de l'interface.

Un Proxy est une classe dynamique qui peut implémenter n'importe quel interface et dont tous les appels de méthodes renvoient vers une seule et unique méthode invoke() qui recoit en paramètre l'objet Method et les arguments correspondant à l'appel...

Il faut d'abord que tu implémentes l'interface InvocationHandler qui définit la méthode invoke(). Cette méthode sera appellée pour toutes les méthodes de ton interface avec en paramètre l'objet Method représentant ta méthode...

Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class ConnectionProxy implements InvocationHandler { private final Connection connection; public ConnectionProxy(Connection conn) { this.connection = conn; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object returnValue = method.invoke(this.connection, args); return returnValue; } }
Ici je me contente d'appeller la méthode sur le champs contenant la véritable instance de Connection, mais tu peux eventuellement rajouter tout le code que tu veux avant et après (par exemple en ajoutant des traitements selon le nom de la méthodes).

Ensuite il faut créer un Proxy :
Code:

1 2 3 4 5 Connection sqlConn = // Ta véritable connection... Connection conn = (Connection) Proxy.newProxyInstance( ClassLoader.getSystemClassLoader(), new Class[]{Connection.class}, new ConnectionProxy(sqlConn) );
Tout les appels de méthode que tu effectueras sur l'objet conn seront renvoyé vers la méthode invoke() de ta classe ConnectionProxy.

Cela peut être intérréssant si tu ne dois modifier que quelques méthodes et que dans la plupart des autres tu te contentes d'appeller la 'véritable' méthode...

[HS] Glob >> En quoi la présence d'une méthode deprecated pose-t-elle problème ?
Si tu developpes une nouvelle application, le compilateur (ou ton EDI) t'indique qu'il est conseillé de ne plus l'utiliser (poux X ou Y raison), et cela ne dérange pas plus que cela...

Par contre en supprimant les méthodes deprecated, Sun forcerait un grand nombre de developpeurs à modifier leurs anciennes applications tout simplement pour modifier quelques appels de méthodes, ce qui pourrait les rendres incompatibles avec les version de Java pour lesquels elles étaient destinés...

Déjà que beaucoups d'entreprises ont du mal à passer à Java 5.0 (et bientôt Java 6.0 ;)) alors que la compatibilité est quasiment assuré, qu'est-ce qu'il en sera si Sun annoncait qu'un grand nombre de méthodes ont été supprimées...

a++

09/02/2006, 14h29
moritan

Merci pour vos réponses avec tout ça je devrais pouvoir résoudre le problème.