Discussion :

[TabrisLeFol]

Bonjour,
Je sais qu'il est possible de charger dynamiquement des classes en Java (même si je ne l'ai pas personnellement experimenté). Est ce que ce type de technique, associé à un test sur la version de la jvm employée permettrait d'interpreter du bytecode relatif au "niveau" de la jvm ? (Autrement dit tester son niveau, puis en fonction de celui-ci, lancer tel ou tel code contenant telle ou telle fonctionnalitée?)
Et est ce une pratique courant ? Ou il y a t il une raison de ne pas le faire ?

D'avance merci

[adiGuba]

Salut,

Est ce que ce type de technique, associé à un test sur la version de la jvm employée permettrait d'interpreter du bytecode relatif au "niveau" de la jvm ? (Autrement dit tester son niveau, puis en fonction de celui-ci, lancer tel ou tel code contenant telle ou telle fonctionnalitée?)

Je ne comprend pas ce que tu veux dire exactement ? Tu pourrais être plus précis ou donner un exemple concret ?

a++

[TabrisLeFol]

Salut,
(voici une reformulation)
Par exemple, a partir de la 1.4, on peut, selon la platforme, faire du pleine écran. Si on a des clients ne disposant que d'une version anterieure (la 1.3 à priori), on ne peut donc pas inclure cette fonctionnalitée dans notre logiciel. Pourtant cette fonctionnalitée pourrait etre exploitée par certains clients.
Il devrait etre possible alors de faire une classe qui utilisera cette fonctionnalitée. Cette classe ne pourra etre utilisée par les 1.3. Par contre si on peut tester la version de la jvm alors on pourrait charger certaines classes avec certaines fonctionnalitées (eg full screen) en fonction de la version du client.
Cela c'est mon raisonnement théorique. Après cela est il technologiquement possible ? Et si c'est le cas, est ce que cela se fait ? Si non, pourquoi ?

D'avance merci.

PS : J'espere avoir été plus clair.

PPS: Full screen est un exemple, je sais que la 1.6 a apporter d'autres fonctionnalitées, malheureusement, je ne connais pas suffisement cette version pour faire l'exemple dessus.

[Baptiste Wicht]

Salut,
(voici une reformulation)
Par exemple, a partir de la 1.4, on peut, selon la platforme, faire du pleine écran. Si on a des clients ne disposant que d'une version anterieure (la 1.3 à priori), on ne peut donc pas inclure cette fonctionnalitée dans notre logiciel. Pourtant cette fonctionnalitée pourrait etre exploitée par certains clients.
Il devrait etre possible alors de faire une classe qui utilisera cette fonctionnalitée. Cette classe ne pourra etre utilisée par les 1.3. Par contre si on peut tester la version de la jvm alors on pourrait charger certaines classes avec certaines fonctionnalitées (eg full screen) en fonction de la version du client.
Cela c'est mon raisonnement théorique. Après cela est il technologiquement possible ? Et si c'est le cas, est ce que cela se fait ? Si non, pourquoi ?

D'avance merci.

PS : J'espere avoir été plus clair.

PPS: Full screen est un exemple, je sais que la 1.6 a apporter d'autres fonctionnalitées, malheureusement, je ne connais pas suffisement cette version pour faire l'exemple dessus.

Donc, si j'ai bien compris, tu voudrais faire un test sur la verison de la JVM et en fonction de ce test appeller des méthodes par réfléxion sur des choses qui sont pas disponibles pour toutes les versions pour permettre de rester compatible. C'est bien ça ?

Je pense que ça doit être possible. Mais est-tu sûr d'avoir besoin de cela ?

[TabrisLeFol]

Presque mais aucun raport avec la reflexion.
Je definie une interface et une instance d'une classe implementant cette interface sera utilisée tout le long du programme.
Cette instance provient de l'instanciation d'une classe chargée dynamiquement et ce en fonction de la version de la jvm. Ainsi vu du programme rien ne change réellement, cependant les fonctions de cette instance permettront d'utiliser les fonctionnalitées supportée par la jvm.

[N_I_C_S]

Salut,
Je ne crois pas qu'il soit nécessaire de charger dynamiquement des classes, etc... On peut très bien s'en tirer en implémentant plusieurs classes héritées d'un type IHM (pour reprendre l'exemple) et, selon la JVM, retourner l'IHM adaptée (pattern Builder).

[TabrisLeFol]

Je ne connaissais pas le nom de ce pattern, mais cela correspond effectivement à ce que je veux faire.
Le chargement dynamique est obligatoire puisque il n'est pas possible (par exemple) d'utiliser des fonctionnalitées 1.4+ avec une 1.3 (genre full screen).
Le code produit est seulement compatible avec les jvm 1.4+ et donc necessite d'être chargé que si la jvm le permet....

[sinok]

Euh j'dis pas mais, ça serait pas un poil plus simple avec un bête script de lancement analysant la commande java -version et lançant la bonne appli en fonction de son retour...
De toute façon avec ta méthode tu es obligé d'avoir le bytecode pour plusieurs versions alors pouquoi ne pas se tourner les pouces au lieu de faire tourner sa tête pour pas grand chose...

[theyankee76]

Autres possibilités bien plus simple :

- Tu déploies une jvm en même temps que ton application. Il y a des softs qui permettent de packager tout cela.
- Tu oblige tes clients à installer telle ou telle jvm au lancement.

Pour ce qui est du chargement dynamique, cela existe avec le Class Loader, mais pour l'avoir utilisé ca fonctionne bien, mais niveau mise en place c'est très galère. Il te faut réécrire une bonne partie de ton code. (moins si tu utilise des interfaces mais tu dois en réécrire quand même.)

Sinon l'idée du pattern builder parait assez approprié. Tu déploie un jar pour chaque version, et suivant ta jvm t'appelle la classe appropriée.

Voici un petit example :

2 jar :
- jvm14.jar
- maClasse14

- jvm15.jar
- maClasse15

Et ca passera très bien à la compilation

Enfin dernière solution que j'utilise :

J'ai tous mes jars nommés identiquement et contenant les mêmes classes (Mais chacun des jars pour une version specifique de l'appli ou de la jvm). Au lancement, je récupère la version de la jvm et je déclare mon classpath suivant mes besoins).