Discussion :

[sekaijin]

Là je blâme parce que les conséquences elles sont déjà prévisibles.
Vu l'impact qu'il a, tout va devoir être refait.

...

nous avons déjà eu ce genre de réaction par le passé. comme lorsqu'un acteur très connu a sorti une machine sans lecteur de disquette. ou lorsqu'on est passé de 32 a 64 bit.
oui ça change la donne mais il ne faut pas exagérer. lorsque ce sera digéré on dira. mais comment on a pu faire sans ça.

A+JYT

[grunt2000]

C'est gentil de part et d'autre d'ironiser,
mais on va bien voir la todo-list des premières entreprises qui voudront migrer.

Je ne vois pas comment à cet instant où l'on constate que pour faire fonctionner des applications il faut soit les remplacer soit les reparamétrer,
dans quelques mois (ou même quelques années) ces mêmes applications pourraient se remettre à fonctionner d'elles-mêmes avec Java 9.

Or une entreprise n'a pas que des applications récentes.
Elle en a qui ont un ou deux ans d'âge,
d'autres qui ont quatre ou cinq ans,
et parfois une ou deux anciennes de plus de cinq ans, voire dix.

Pour le moment, pas d'urgence : elles peuvent vivre avec en Java le plus ancien : Java 7, quoi qu'il soit en EoS / EoL ; leur urgence immédiate est surtout de migrer les systèmes employant encore Java 6, car eux deviennent dangereux.
Mais quand viendra le temps où on leur dira, en 2019 mettons, "Passez à Java 9, cette fois.", eh bien ce jour-là, les problèmes que posent aujourd'hui Java 9 n'auront pas changé d'un iota par rapport à aujourd'hui. Elles devront tout réviser, recompiler, re-packager et obtenir des solutions d'éditeurs divers pour remettre droites les applications qu'elles ont, et qui auront alors trois, six ou sept, voire plus de sept ou douze ans d'âge.

Vous pensez : "De l'eau sera passé sous les ponts d'ici là, et les services informatiques se seront préparés et sauront su faire face.".
Certainement. Mais avec beaucoup plus d'efforts et de difficultés, à mon sens, qu'avec toutes les versions antérieures de Java.

[yildiz-online]

Pour le moment, pas d'urgence

Effectivement, le support étendu de java 8 est prévu jusque 2025, d'ici là, on peut espérer que les société auront eu l'opportunité de migrer / décommissioner leur anciennes applications...

http://www.oracle.com/technetwork/ja...ol-135779.html

[Mickael Baron]

nous avons déjà eu ce genre de réaction par le passé. comme lorsqu'un acteur très connu a sorti une machine sans lecteur de disquette. ou lorsqu'on est passé de 32 a 64 bit.
oui ça change la donne mais il ne faut pas exagérer. lorsque ce sera digéré on dira. mais comment on a pu faire sans ça.

Pas faux.

Mickael

[genamiga]

Je travaille sur une application Java depuis des années.

J'ai commencé avec Java 6 et migrer vers Java 7 puis Java 8.
A chaque fois la compatibilité était parfaite (dans mon cas).

Ensuite petit à petit on réécrit du code pour profiter de la nouvelle version...en douceur.

Et là...C'est la rupture brutale...Pas de compatibilité...ça ne fonctionne pas du tout.

Je trouve qu'il est impératif qu'une application faite sous Java 8 fonctionne directement sous Java 9...c'est de la folie ce que Oracle a fait.
A la rigueur abandonner Java 6 et 7 mais pas le 8...c'est du grand n'importe quoi !

En plus vous avez vu le Oracle Java SE Public Updates...plus de maj après Sep 2018 pour Java 8.

Merci Oracle.

[yildiz-online]

Et là...C'est la rupture brutale...Pas de compatibilité...ça ne fonctionne pas du tout.

Qu'est-ce qui ne fonctionne pas?

[Grogro]

Et là...C'est la rupture brutale...Pas de compatibilité...ça ne fonctionne pas du tout.

C'est Jigsaw qui fout la merde ?

[grunt2000]

Eh bien, je maintiens mes dires.
Quatre mois après sa sortie, ici, sur ce forum Java, il n'y a aucun sujet, aucune question technique relative à Java 9.
Un contradicteur me trouvera peut-être deux ou trois liens, bien sûr. Mais fait-il 1% des questions ?

À l'inverse de Java 8 à sa sortie, qui avait provoqué l'engouement et où les illustrations et questions n'avaient pas tardé à venir quant à son emploi,
personne ne l'a utilisé dans un développement professionnel au point d'avoir eu à interroger la communauté. C'est un fait remarquable.

Je veux bien qu'on me dise qu'il faut demeurer patient, et qu'il est un succès,
à condition qu'on me décrive alors ce qui aurait été un échec.

[yildiz-online]

Pour ma part ce qui est bloquant:

-Au boulot, ce n'est pas une LTS, et l'ecosystème autour n'est pas mature, maven qui nécessite des versions m1 de ses plugins pour être compatible.
-Au niveau perso, pas de jvm windows 32 bits, ce qui fait que je dois compiler les dépendances natives en 64, donc priorité plus basse.

Java 9 est intéressant, mais la migration n'est pas aussi transparente qu'avec le 8, donc forcément ça traine, d'autant plus que la feature majeure, la modularité, est plus intéressante pour les architectes que les devs, idem pour la réduction de l'empreinte mémoire.

[adiGuba]

Java 9 est intéressant, mais la migration n'est pas aussi transparente qu'avec le 8, donc forcément ça traine, d'autant plus que la feature majeure, la modularité, est plus intéressante pour les architectes que les devs, idem pour la réduction de l'empreinte mémoire.

+1

Je rajouterais que Java 8 apportait de nombreuses nouveautés dans le langage (lambda, référence de méthode, méthodes par défaut dans les interfaces) avec un impact sur de nombreuses APIs (ancienne ou nouvelle).

Java 9 comporte un gros morceau avec Jigsaw, mais coté langage cela n'apporte rien pour le développeur.

[genamiga]

Code :

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

java -jar Omega.jar

Code :

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

1
2
3
4
5
6
7
8
9
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
        at Outils.Options.lireOptions(Options.java:456)
        at Outils.Options.setupOptions(Options.java:343)
        at Omega.OmegaApp.main(OmegaApp.java:82)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        ... 3 more

L'application Omega fonctionne parfaitement sous Java 8

[professeur shadoko]

tu as essayé avec java --add-modules javax.xml.bind,javax.xml, etc. ... ?

[genamiga]

Pareil...

Apparement ces librairies font partie de JavaEE et ne sont plus accessibles directement dans Java9 alors qu'elles l'étaient avec les versions précédentes... Elles seront probablement supprimées de Java 10.

Que faire ?

[grunt2000]

Pour chaque ligne de commande lancée par Java 9 alors qu'elle était autrefois utilisée en Java 8, il pourra falloir rajouter un --add-modules avec des paramètres à sélectionner à chaque fois en fonction des manques constatés, empiriquement, ou à l'aide d'un outil d'analyse dédié, quand il existera.

Pour les composants tierce partie embarqués dans un logiciel et dysfonctionnant par des NoClassDefFoundError, si l'on ne peut les résoudre par un --add-modules inséré quelque-part, il faudra demander leur mise à jour à leur éditeur.

[professeur shadoko]

Pour chaque ligne de commande lancée par Java 9 alors qu'elle était autrefois utilisée en Java 8, il pourra falloir rajouter un --add-modules avec des paramètres à sélectionner à chaque fois en fonction des manques constatés, empiriquement, ou à l'aide d'un outil d'analyse dédié, quand il existera.

Pour les composants tierce partie embarqués dans un logiciel et dysfonctionnant par des NoClassDefFoundError, si l'on ne peut les résoudre par un --add-modules inséré quelque-part, il faudra demander leur mise à jour à leur éditeur.

pas nécessaire de se taper la recherche des détails
il y a une possibilité de passer à --add-modules des paramètres comme ALL-DEFAULT, ALL-SYSTEM, ALL-MODULE-PATH.

[genamiga]

Ces librairies sont deprecated regardez là

https://docs.oracle.com/javase/9/mig...B-D931174C09A3

Et quand Oracle supprimera ces librairies on fera quoi ?

Et je le rappelle dernière maj Java8 en septembre 2018...

Dire qu'au départ j'ai choisi Java entre autre pour sa rétro compatibilité...

Merci Oracle.

[grunt2000]

Je pense qu'Oracle finira par sortir une version patchée qui provoquera un chargement en ALL de tous les modules par défaut,
et c'est explicitement que les développeurs mettront des --remove-modules à la place... s'ils y tiennent vraiment !
Ce sera plus facile d'emploi, si l'emploi de la fonctionnalité modulaire n'est plus imposée.

C'est la seule solution facile et immédiate que je vois pour donner une chance à Java 9 de repartir.

Car aujourd'hui, six mois (ou presque) après son lancement, personne ne l'a encore utilisé.
Il n'a encore servi à rien.
Je n'ai jamais connu pareil fiasco.

(enfin ... à part Struts 2).

[yildiz-online]

Car aujourd'hui, six mois (ou presque) après son lancement, personne ne l'a encore utilisé.
Il n'a encore servi à rien.
Je n'ai jamais connu pareil fiasco..

C'est un peu normal, les librairies doivent pouvoir continuer à tourner sur des version de java plus anciennes, les libs qui requièrent absolument java 8 sont déjà rares, alors java 9...

Cependant la JEP238 (multi-release jar) devrait permettre de mitiger la situation, mais ça ajoute un coût de maintenance certain.

Sinon certaines libs s'y mettent, c'est le cas de SLF4j, hibernate validator, spring-boot entre autre,... donc c'est pas si mal.

Pour ma part, j'ai migré mon code perso, pas toujours une sinécure (activemq passe mal par exemple), mais globalement, c'est un changement très positif, d'un point de vue encapsulation et exposition des API, c'est une vraie avancée. Et si on l'aime pas, on peut toujours passer sur java 9 sans utiliser les modules...

[genamiga]

En suivant les recommandations de Oracle trouvées sur https://docs.oracle.com/javase/9/mig...B-D931174C09A3, j'ai enfin une solution.

Pas très élégante et qui demandera sans doute de l'attention dans l'avenir.

Il faut récupérer les libs Java EE dont on a besoin sur Maven Central et les ajouter explicitement à son projet.

Alors cela fonctionne sous Java 8 et 9, et cela fonctionnera aussi quand Oracle supprimera ces libs d'une version future de Java.

[deltree]

C'est un peu normal, les librairies doivent pouvoir continuer à tourner sur des version de java plus anciennes, les libs qui requièrent absolument java 8 sont déjà rares, alors java 9...

Cependant la JEP238 (multi-release jar) devrait permettre de mitiger la situation, mais ça ajoute un coût de maintenance certain.

Sinon certaines libs s'y mettent, c'est le cas de SLF4j, hibernate validator, spring-boot entre autre,... donc c'est pas si mal.

Pour ma part, j'ai migré mon code perso, pas toujours une sinécure (activemq passe mal par exemple), mais globalement, c'est un changement très positif, d'un point de vue encapsulation et exposition des API, c'est une vraie avancée. Et si on l'aime pas, on peut toujours passer sur java 9 sans utiliser les modules...

Je fais justement du Spring boot en java 9, et on peut difficilement dire qu'ils s'y mettent, ils n'utilisent pas le fichier module-info, et ils proposent à la place d'ajouter des --add-modules pour que lancement fonctionne, c'est simplement compatible java 9 sans plus.

Pour slf4j oui il font une version java9 dans une branche spécifique, qui est encore en bêta.

Après je regrette pas mon choix du java 9, mais j'ai un peu l'impression d'essuyer les platres.