Discussion :

[Underzeci]

Bonjour

J'entends souvent parler lorsqu'on travaille sur un projet des différents problèmes qu'il peut se produire lorsqu'on change de version de java (passage de java 6 à java 7 par exemple).
En gros à quoi faut il faire attention lorsqu'on migre de version ?

Merci

[joel.drigo]

Salut,

Je n'ai pas eu de problèmes généraux quant à la syntaxe ou aux packages standards en passant de 1.6 à 1.7. J'en ai eu entre 1.4 et 1.5 (avec xpath), ou de 1.7 à 1.6 (forcément), mais pas de 1.6 à 1.7. Il peut y avoir en revanche des nouveaux warnings (comme le @override (ou le default des switch) sur les méthodes d'interface, mais je ne sais plus si c'était entre 1.5 et 1.6, ou 1.6 et 1.7).
Ensuite, il se peut toujours qu'il y a ait des problèmes particuliers, surtout à l'exécution, en particulier de compatibilité avec d'autres API, mais ça tu ne pourras les constater qu'en testant, comme par exemple sur Mac, avec Eclipse, les problème de l'abandon de la JRE Apple au profit de celle d'Orable/OpenJDK, avec l'implémentation bas niveau (apple vs sun), ou encore des changements dus à la sécurité (comme entre je ne sais plus quelle version de 1.6 et sa suivante, et l'équivalente 1.7, avec Runtime.exec qui plante avec la version à un seul argument).

[tchize_]

Ce qu'il y a de bien avec oracle, c'est qu'il y a des release notes qui précisent tout ce qui peut poser problème lors de l'upgrade. A toi de faire le tri


http://www.oracle.com/technetwork/ja...ml#knownissues

[Underzeci]

Ce qu'il y a de bien avec oracle, c'est qu'il y a des release notes qui précisent tout ce qui peut poser problème lors de l'upgrade. A toi de faire le tri


http://www.oracle.com/technetwork/ja...ml#knownissues

Merci, je vais regarder à un oeil à ça

[Underzeci]

Salut,

Je n'ai pas eu de problèmes généraux quant à la syntaxe ou aux packages standards en passant de 1.6 à 1.7. J'en ai eu entre 1.4 et 1.5 (avec xpath), ou de 1.7 à 1.6 (forcément), mais pas de 1.6 à 1.7. Il peut y avoir en revanche des nouveaux warnings (comme le @override (ou le default des switch) sur les méthodes d'interface, mais je ne sais plus si c'était entre 1.5 et 1.6, ou 1.6 et 1.7).
Ensuite, il se peut toujours qu'il y a ait des problèmes particuliers, surtout à l'exécution, en particulier de compatibilité avec d'autres API, mais ça tu ne pourras les constater qu'en testant, comme par exemple sur Mac, avec Eclipse, les problème de l'abandon de la JRE Apple au profit de celle d'Orable/OpenJDK, avec l'implémentation bas niveau (apple vs sun), ou encore des changements dus à la sécurité (comme entre je ne sais plus quelle version de 1.6 et sa suivante, et l'équivalente 1.7, avec Runtime.exec qui plante avec la version à un seul argument).

Salut,

Merci de ta réponse, c'est beaucoup plus clair pour moi, clairement

Oui je faisais davantage référence au passage de 1.7 à 1.6 suite à un passage de 1.6 vers 1.7 (je crois qu'on appelle cela reverse engineering), lorsqu'on souhaite retourner à une version précédente par exemple. Les différents problèmes qu'on peut rencontrer et comment y remédier (ce à quoi il faut faire attention).

Cela dit, qu'entends tu par "compatibilité avec d'autres API" ? Est ce les classes de rt.jar ? Je ne vois pas en fait le rapport entre les autres API (qui sont pour moi des classes compilés) et le JRE Apple ou Oracle (quand on utilise l'API Swing par exemple, que ce soit JRE Apple ou Oracle, c'est la même chose).

[joel.drigo]

Oui je faisais davantage référence au passage de 1.7 à 1.6 suite à un passage de 1.6 vers 1.7 (je crois qu'on appelle cela reverse engineering), lorsqu'on souhaite retourner à une version précédente par exemple. Les différents problèmes qu'on peut rencontrer et comment y remédier (ce à quoi il faut faire attention).

Euh, non, le Reverse Engineering c'est retrouver les spécifications à partir du produit fini. Tu parles juste de revenir en arrière... Le passage de 1.7 à 1.6 est beaucoup plus sensible. S'il est effectué dans le cadre d'un simple retour en arrière sans avoir rien changé au code 1.6 pour passer en 1.7, ça va être simple. Mais dès que tu adaptes, là il faudra revenir en arrière. Et ça peut être du boulot. Par exemple, si tu as remplacé tout tes try/finally de fermeture de flux par des try-with-resource, et bien il faudra refaire l'inverse pour repasser en 1.6. Et si tu as remplacé des if/else if sur String par des switch, idem. Le mieux étant de faire un backup du projet initial, pour revenir en arrière, plutôt que se retaper le boulot de tout remodifier dans l'autre sens.

Cela dit, qu'entends tu par "compatibilité avec d'autres API" ? Est ce les classes de rt.jar ? Je ne vois pas en fait le rapport entre les autres API (qui sont pour moi des classes compilés) et le JRE Apple ou Oracle (quand on utilise l'API Swing par exemple, que ce soit JRE Apple ou Oracle, c'est la même chose).

Les autres API, c'est je ne sais POI par exemple, ou JDOM... parfois, un simple bug va t'obliger à migrer vers la nouvelle version plus en adéquation avec la 1.7, mais ne fonctionnant pas avec la 1.6. Ou encore pour une appli web avec des trucs un peu touchy en relation avec le serveur, avec du spécifique jboss, du spécifique weblo, etc.
Et pour mon cas, l'API graphique que j'utilise c'est SWT, sous Eclipse RCP, qui en plus d'avoir une composante native et fortement lié à la JVM. Souci par exemple lors du passage de la 1.6 Apple à la 1.7 Oracle, le drag and drop entre SWT et AWT ne fonctionne plus. Autre souci de compatibilité d'API : passage de 1.6 à 1.7 m'oblige de changer de version d'Eclipse, donc de subir les problématiques de non compatibilité ascendante : des classes n'existent plus, des interfaces ont été remplacées par des abstractions, etc, et le lifecycle applicatif a complètement changé (n'utilise plus les mêmes classes, les mêmes méthodes, le même système) et comme il a été surchargé pour gérer des spécificités, il faut réécrire une partie.

[Underzeci]

OK good. Je n'ai pas bien comprista dernière partie à cause des termes trop techniques pour moi mais je vais prendre soin de relire ça à tête reposée. Merci

[bouye]

Certaines mises a jour majeure de Java/la JVM ont parfois introduit des pertes de performances dans certaines modules tels que JDBC voir même par effet de bord des bugs dans des libs tierces ou des services tiers qui fonctionnaient très bien avec la version précédente. Ceci dit, souvent le soucis est assez vite documenté et/ou corrigé ou la lib tierce/le service tier en question ont été mis a jour pour contourner le soucis.

En plus ici la JVM 1.7 étant déjà en fin de vie depuis longtemps, la plupart des gros soucis pénalisant qui étaient apparus lors de la toute première version ont été corrigés depuis longtemps. Bon après, l'autre soucis c'est que désormais tu n'as plus guère que des corrections de sécurité pour le JDK 7, donc si tu trouves un bug/comportement bizarre/problème ou manque dans l'API, il y a toutes les chances du monde que ce derniers ait été corrige dans le JDK 8 (ou même 9) mais c'est une autre histoire.