Java 1.5 et Java 1.4

Bonjour à tous.

Je dois reprendre une application web (Struts 1.1) développée en Java 1.4 fonctionnant sur Tomcat 4.4.

Afin de pouvoir utiliser la vue Servers, faire du debogage pas à pas etc, j'ai choisi de monter mon environnement de dev avec Java 1.5, Tomcat 4.1 et Eclipse 3.3.2 (j'utilise WTP, qui n'accepte que du Java 1.5 ou supérieur).

Est-ce que je peux compiler (compliance level 5.0) et générer mon war sous mon environnement de dév puis le faire tourner sur un environnement avec Java 1.4 et Tomcat 4.4 ?

Est-ce que la compatibilité entre java 1.4 et 1.5 est ascendante ? Descendante ? Ou bien il faut avoir la même version de Java entre la compilation/génération du war et l'environnement d'exécution ?

Ou encore mieux, y t-il la possibilité d'utiliser la même chose proposée dans WTP, à savoir un monitoring avec possibilité de debugging pas à pas tout en ayant un Eclipse tournant sur Java 1.4 (je précise que ce n'est pas ce que propose le Tomcat Plugin de Sysdeo)

En gros, si vous m'avez compris, j'ai besoin de quelques infos et précisions sur le sujet, merci !

si tu développe avec java 1.5, tu aura du code qui pourra s'exécuter sur des jvm 1.5 et supérieures. Tu peux donner l'instruction au compilateur de faire des .class compatible 1.4, 1.3 meme 1.2 il me semble. Par contre, le gros problème, c'est que les api ne sont pas les meme. Avoir du code capable de tourner sur jvm 1.4 mais qui dépend de classes ou méthodes apparues en 1.5 ne sera pas utile -> faudra bien choisir tes classes. De plus le compiltateur refusera la compilation vers des ancienne version si tu utilise des options de la nouvelles jvm (exemple un code avec des Generics ne pourra jamais etre compilé avec comme target jvm 1.4)

PS: pourquoi tomcat 4 pour un nouveau developpement? Cette version est antédéluvienne et bugguée.

Salut,

Citation:

---

Envoyé par tchize_

Tu peux donner l'instruction au compilateur de faire des .class compatible 1.4, 1.3 meme 1.2 il me semble. Par contre, le gros problème, c'est que les api ne sont pas les meme. Avoir du code capable de tourner sur jvm 1.4 mais qui dépend de classes ou méthodes apparues en 1.5 ne sera pas utile -> faudra bien choisir tes classes.

---

C'est même plutôt dangereux : le code compilera bien et le programme pourrait bien fonctionner jusqu'à l'appel d'une méthode anodine... :?

:arrow: Il est préférable d'utiliser le JDK correspondant à la version minimum sur laquelle on veut que l'application tourne !

a++

Oui, finalement j'ai indiqué 1.4 au niveau des sources et des classes compilées.

Je fais systématiquement des tests sur un environnement ou le jdk 1.4 est installé.

A voir si les évolutions à réaliser dans l'application sont plus ou moins majeures mais bien évidemment, je ferai attention aux choix des classes (les développements resteront dans la veine de ceux déjà réalisés...).

Eclipse ne génère pas une erreur ou un warning si on tente d'utiliser une fonctionnalité uniquement apparue depuis la 1.5 ?

PS : ce n'est pas un nouveau développement mais une TMA sur une ancienne application, je préfère donc être au plus proche de l'environnement de production pour éviter toute surprise, d'où l'utilisation d'un Tomcat 4.

@adiGuba : je suis d'accord mais sans l'utilisation de WTP (qui nécessite jdk 1.5 ou supérieur), je ne peux pas faire de pas à pas et si je dois recompiler puis redémarrer Tomcat toutes les 5 min, je te laisse imaginer la perte de temps...

Citation:

---

Envoyé par djalouk

Eclipse ne génère pas une erreur ou un warning si on tente d'utiliser une fonctionnalité uniquement apparue depuis la 1.5 ?

---

Si on utilises une nouveauté du langage oui... Mais pas si on utilise une nouvelle méthode car il n'a aucun moyen de la savoir.
Par exemple ceci compile en 1.4 avec un JDK 1.5 mais plantera en 1.4 :

Code:

---

1 2	String str = "Hello You !"; str = str.replace("You", "World");

---

:arrow: Lors de la compilation si tu indique un target 1.4, le compilateur te génèrera bien un bytecode compatible 1.4.
Par contre il va utiliser l'API de Java 1.5 pour vérifier les appels de méthode, et générer un appel à la méthode String.replace(CharSequence,CharSequence) qui n'existe pas en 1.4... et ce n'est qu'à l'exécution sur un vrai JRE 1.4 que tu va rencontrer le problème !!!


Bref ce serait mieux si tu pouvais migrer ton serveur sur du Java5/Tomcat5...

Sinon je te conseillerais d'utiler une tache Ant ou tout autre outils pour forcer une recompilation avec un vrai JDK 1.4 avant la mise en production, pour détecter ce type d'erreur...


a++

J'ai commencé à prendre en main l'application, j'ai fait une recherche sur .replace et j'ai trouvé cette ligne :

Code:

---

valeur = ((Double)reponse).toString().replace('.',',');

---

Le code serait finalement en Java 1.5 ?

Non car il ne s'agit pas de la même méthode :
String.replace(char,char) existe depuis toujours,
String.replace(java.lang.CharSequence,java.lang.CharSequence) est apparut avec Java 5...

:arrow: Il est inconcevable de gérer cela à la main, et le compilateur ne peut pas détecter ce type de problème. Donc la solution est bien de compiler avec un vrai 1.4 ;)

a++

c'est pas la meme méthode.

De plus, ok wtp exige java 5 pour fonctionner, mais est-ce qu'il exige que ton projet pointe sur un compilateur java 5? Parce qu'il faut faire la distrinction entre

1) la jvm utilisée par eclipse pour fonctionner
2) la jvm utilisée par eclipse pour compiler (spécifique au projet)
3) éventuellement, la jvm utilisée par eclipse pour exécuter.

Il me semblerait judicieux, au point 2, de faire pointer ton projet sur une jdk 1.4 si possible.

Citation:

---

Envoyé par tchize_

2) la jvm utilisée par eclipse pour compiler (spécifique au projet)
3) éventuellement, la jvm utilisée par eclipse pour exécuter.

---

J'ignorais qu'il y avait aussi une distinction entre la JVM du projet et la JVM utilisé par Tomcat...

Mais en fait c'est tout à fait logique et cela simplifie le problème.


Bref la solution :

• Installe un vrai JRE 1.4 ou mieux un JDK 1.4 (eclipse intègrera les sources pour permettre la ctrl+clic ;)).
• Dans les préférences d'eclipse, "Java->Installed JREs", ajoute une nouvelle "VM Standard" en spécifiant le répertoire d'install de ton JRE/JDK 1.4.
• Dans les propriété de ton projet, modifie le "build-path" en supprimant la bibliothèque de Java 5, puis ajoute une nouvelle JRE en prenant ton JRE 1.4

:arrow: Ton code est désormais compilé avec la vrai API de Java 1.4 !


a++

PS : Toutefois il est préférable de quand même faire des tests sur du vrai 1.4 avant la mise en prod...

Merci pour votre aide.

La solution de adiGuba est la bonne.

Petit test rapide, l'auto-suggestion pour la méthode replace ne propose que String.replace(char,char).

Je ferai attention a effectuer des tests.

J'ai également fait pointer Tomcat vers le jre1.4.

Merci à vous !

War testé sur l'environnement cible (jre1.4 uniquement et Tomcat 4.1), ça à l'air ok.