IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

Interface et JDK multiple.


Sujet :

Langage Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé
    Avatar de moritan
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juin 2005
    Messages
    687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juin 2005
    Messages : 687
    Par défaut 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

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    Juin 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Juin 2005
    Messages : 94
    Par défaut 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
    ???

  3. #3
    Gfx
    Gfx est déconnecté
    Expert confirmé
    Avatar de Gfx
    Inscrit en
    Mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 43

    Informations forums :
    Inscription : Mai 2005
    Messages : 1 770
    Par défaut
    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.

  4. #4
    Membre éprouvé
    Avatar de moritan
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juin 2005
    Messages
    687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juin 2005
    Messages : 687
    Par défaut
    Désolé effectivement en me relisant, je ne suis pas très clair, voir limite opaque...

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.?

  5. #5
    Gfx
    Gfx est déconnecté
    Expert confirmé
    Avatar de Gfx
    Inscrit en
    Mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 43

    Informations forums :
    Inscription : Mai 2005
    Messages : 1 770
    Par défaut
    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

  6. #6
    Expert éminent
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Billets dans le blog
    1
    Par défaut
    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++

  7. #7
    Membre éprouvé
    Avatar de moritan
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juin 2005
    Messages
    687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juin 2005
    Messages : 687
    Par défaut
    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.

  8. #8
    Membre averti
    Inscrit en
    Février 2006
    Messages
    25
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 25
    Par défaut
    Une solution :

    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
    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();
        }
     
        // ....

  9. #9
    Membre chevronné
    Avatar de Glob
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Avril 2002
    Messages
    428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Avril 2002
    Messages : 428
    Par défaut
    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

    (*) voire plus pour certaines

  10. #10
    Expert éminent
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Billets dans le blog
    1
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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++

  11. #11
    Membre éprouvé
    Avatar de moritan
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juin 2005
    Messages
    687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juin 2005
    Messages : 687
    Par défaut
    Merci pour vos réponses avec tout ça je devrais pouvoir résoudre le problème.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Application avec multiples interfaces graphiques
    Par Boobatt dans le forum AWT/Swing
    Réponses: 1
    Dernier message: 08/04/2007, 17h25
  2. Réponses: 3
    Dernier message: 30/08/2006, 15h35
  3. [Language][1.5]Question interfaces multiple:
    Par FreshVic dans le forum Langage
    Réponses: 16
    Dernier message: 18/11/2005, 09h41
  4. [LG]Interfaces et multiples définitions
    Par fatt dans le forum Langage
    Réponses: 2
    Dernier message: 15/04/2004, 22h41
  5. [Kylix] heritage multiple et interfaces :(
    Par le_barbu dans le forum EDI
    Réponses: 4
    Dernier message: 26/01/2004, 19h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo