Discussion :

[JPDMJC]

Bonjour,

Le contexte :

Je développe une bibliothèque qui doit être compatible Java 5. Jusque là j'utilisais le JDK 1.5, pas de problème. L'objectif est de rester compatible Java 5.

J'ai regardé du côté du JDK 1.6, grandement apprécié certaines méthodes, et donc réutilisé le code/principe de méthodes apparues à partir du JDK 1.6, comme par exemple la méthode isEmpty de la classe String, ou encore setReadable de File. Je suis donc toujours en 1.5.

Cette pratique me paraissait assez logique : j'avais déjà essayé - avec un JDK 1.5 - de spécifier comme format de la cible (paramètre "-version" de javac) la 1.4, et me suis naturellement pris des erreurs me disant que, par exemple, les annotations n'étaient pas supportées en Java 1.4.

Cependant, imaginez ma surprise quand j'ai essayé ceci :
J'utilise maintenant le JDK 1.6;
J'utilise aussi directement du code du JDK 1.6, par exemple j'utilise isEmpty() sur mes objets String. C'est du 1.6.
Je précise le format de ma cible (-version) : Java 1.5.
Je m'attendait à des messages d'erreurs me disant que isEmpty() est inconnu en Java 5, mais que neni, ça passe très bien. A vrai dire, en programmant en Java 6, MAIS en spécifiant le niveau Java 5, le JAR généré est compatible Java 5.

Du moins c'est ce dont je me suis aperçu ce soir sur mon projet. Dans un sens cela me paraît logique car les sources que j'ai vu en 1.6 sont faites avec du 1.5, le compilateur s'arrangerait donc avec tout ça, et c'est très sympa. Et puis les annotations & co existent en 1.5 (pas comme en 1.4).
Ou pas.

Deux petites questions

-1- Devrais-je tout de même retourner sous un JDK 1.5 ? J'avoue aimer programmer en Java 6 (ou 1.6, excusez mes éventuelles erreurs de convention ^^), ça m'évite un bête copier-coller. Et puis mon projet compile beaucoup plus vite avec un JDK 1.6 qu'avec un 1.5. Et ça me permettrait aussi de virer mon JDK 1.5, tant qu'on y est !
Le cas 1.6 - 1.5 est-il un cas particulier ?

-2- J'essaie de maintenir une Javadoc complète, et utilise donc le tag @version. Vu que j'utilise des méthodes 1.6 tout en ayant des sources 1.5 : du point de vu de l'utilisateur de la librairie je devrais mettre @since 1.5, mais du point de vue de celui qui reprend les sources, il devrait s'attendre à un @scince 1.6, non ?
Et puis il faut un JDK 1.6, même si au final une JRE 1.5 suffit.
Alors, @since 1.6 ou @since 1.5 pour un code 1.6 mais cible 1.5 ?


Un grand merci pour avoir lu ce message, et merci d'avance pour vos conseils

[sinok]

Si celà concerne jeuste les méthode sur les Strings rediriges toi vers Jakarta commons lang et sa classe StringUtils qui regroupe un paquet de méthodes statiques permettant de tester le contenu de chaines. Sinon pour le compilo, il trouve bien les erreurs dues à la syntaxe entre les deux versions, mais pas au niveau des méthodes ajoutées entre deux versions.

Donc si la version cible de java est la 5, il faut utiliser un compilo java 5 sinon ce genre d'erreurs sont probables

[adiGuba]

Salut,


Ton problème est "normal"...

• Le paramètre -version indique au compilateur qu'il doit utiliser les spécifications du langage de la version indiqué (assert en 1.4, Generics, enum, annotations, etc. en 1.5...). Par exemple avec un -version 1.4 on ne pourra pas utiliser les annotations car elles n'existaient pas, et on peut utiliser 'enum' comme nom de variable (ce qui est impossible en 1.5 car c'est devenu un mot-clef).
  
  
• Le paramètre -target indique au compilateur les spécifications qu'il doit utiliser pour générer le bytecode.
  Par exemple en 1.4 le bytecode peut contenir des informations sur les assertions, en 1.5 il contient les annotations, ...

Mais le problème est que le compilateur a besoin de connaitre l'API afin de pouvoir compiler ton code, afin de vérifier l'existence des classes et méthodes. Il ne peut pas utiliser le tag javadoc @version car cette information n'étant pas obligatoire il y a de forte chance qu'il y ai des lacunes...

Par défaut le compilateur utilise l'API de sa version, et pourrait donc tout à fait faire correspondre une méthode inexistante dans la version cible.

Si tu veux compiler pour du 1.5 avec un compilateur 1.6, tu dois lui passer toutes les classes de l'API de Java 1.5 (contenu dans le fichier rt.jar du JRE) afin que le compilateur puisse vérifier les classes/méthodes et faire ses liaisons. Pour cela il faut utiliser -bootclasspath, ce qui donnerait :

Code :

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

javac -version 1.5 -target 1.5 -bootclasspath _chemin_vers_jre_/lib/rt.jar -classpath ...

Ces trois paramètres (-version, -target et -bootclasspath) sont obligatoire lorsque tu veux faire de la cross-compilation (a noter toutefois que target peut être implicite selon les versions).


Donc si tu veux compiler vers du 1.5 avec un compilateur 1.6, tu dois au moins conserver un JRE 1.5...

Mais le plus simple à mon avis serait quand même d'utiliser un JDK 1.5

a++


PS : En ce qui concerne @version dans une librairie, on utilise la version d'apparition dans la librairie et non pas la version de Java.

[JPDMJC]

Un énorme merci

Je me rend compte de mon imprécision ^^ : je tourne sous NetBeans (6), et avais joué avec le "Source/Binary format" du projet. Je me suis sans nul doute mélangé les pinceaux avec -target et -source. Bon en fait je me suis royalement mélangé les pattes et confondu les deux paramètres.
J'avais aussi fait la bêtise de ne tester qu'à partir de NetBeans sur un poste où j'ai les JDK/JRE 1.5 et 1.6, alors que sur un poste seulement pourvu d'une JRE 1.5 j'ai bien une erreur d'exécution me disant qu'il ne trouve pas certaines méthodes 1.6 ^^. Pfiou .... ô désespoir
Je vais retourner un peu en ligne de commande histoire de bien assimiler tout ça.

Merci encore.

[adiGuba]

Avec les EDI en général tu peux spécifier le JDK/JRE à utiliser selon le projet...

Cela te permet d'utiliser telle ou telle version selon le cas

a++