Java 9 est disponible, la plateforme se met aux modules tour d'horizon des nouveautés

Version imprimable

Voir 40 message(s) de cette discussion en une page

25/09/2017, 08h42
sekaijin

Citation:

Envoyé par grunt2000

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
25/09/2017, 09h35
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.
25/09/2017, 10h19
yildiz-online

Citation:

Envoyé par grunt2000

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
25/09/2017, 12h11
Mickael Baron

Citation:

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
20/10/2017, 13h37
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.
20/10/2017, 15h16
yildiz-online

Citation:

Envoyé par genamiga

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

Qu'est-ce qui ne fonctionne pas?
20/10/2017, 15h32
Grogro

Citation:

Envoyé par genamiga

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

C'est Jigsaw qui fout la merde ?
28/01/2018, 06h24
grunt2000

Java 9 est un four

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.
28/01/2018, 09h05
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.
28/01/2018, 09h36
adiGuba

Citation:

Envoyé par yildiz-online

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.

Code:

java -jar Omega.jar

Code:

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

05/03/2018, 18h12
professeur shadoko

tu as essayé avec java --add-modules javax.xml.bind,javax.xml, etc. ... ?
06/03/2018, 09h54
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 ?
06/03/2018, 15h37
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.
06/03/2018, 19h16
professeur shadoko

Citation:

Envoyé par 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.

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.
07/03/2018, 16h03
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.
07/03/2018, 16h14
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).
07/03/2018, 20h10
yildiz-online

Citation:

Envoyé par grunt2000

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...
09/03/2018, 08h55
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.
09/03/2018, 14h59
deltree

Citation:

Envoyé par yildiz-online

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.

Voir 40 message(s) de cette discussion en une page