Tutoriel pour comprendre les futures fonctionnalités modulaires de Java 9

La société Soat, société d'ingénierie et de conseil en informatique vous propose un tutoriel pour comprendre les futures fonctionnalités modulaires de Java 9 via JIGSAW.

Citation:

---

Dès le début du projet, une partie de la communauté Java s'est opposée assez fermement à l'idée d'un Java SE modulaire. Leur argument, très légitime, était le risque de la perte de stabilité de la plateforme, stabilité qui a contribué grandement à la réputation et au succès de la plateforme Java.

La peur des grands changements était là. Heureusement, elle n'a pas été un frein à l'évolution. C'est elle, malgré la complexité et les risques non négligeables liés à la transition vers une plateforme modulaire, qui a modelé, au fil des discussions entre partenaires, le projet dans sa conformation actuelle. En effet, une fois le projet adopté, sa feuille de route n'a cessé de changer en raison de grosses difficultés techniques et des choix de solutions qui n'ont pas été faciles. Initialement prévu avec Java 7, le projet s'est vu reporté en Java 8, puis finalement en Java 9.

---

Bonne lecture. ;)

Vous pouvez partager vos commentaires dans cette discussion.

Mickael

Salut,



Attention l'exemple donné semble venir d'une vieille version.
Les mot-clefs require/export/provide prennent un 's', le versionning est laissé aux profits d'outils spécialisé...

Sauf erreur de ma part la dernière version en date des spécifications est ici : http://openjdk.java.net/projects/jigsaw/spec/sotms/



Un exemple plus actuel serait celui-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

// On déclare le module (peut avoir le même nom que le package - ou pas) module com.mydomain.mymodule {   // On déclare l'utilisation d'un autre module : // (caché des autres modules : on l'utilise en interne seulement) requires java.xml;   // On déclare l'utilisation d'un autre module en public : // (visible des autres modules automatiquement) requires public java.sql;   // On déclare les packages que l'on veut rendre visible : // Les classes des autres packages du module seront invisible même si déclarrées public ! exports com.mydomain.mymodule; exports com.mydomain.mymodule.subpackage;     // On déclare les packages que l'on veut rendre visible seulement pour certains modules "amis" : exports com.mydomain.mymodule.hiddenpackage to com.mydomain.myothermodule;   // On déclare l'utilisation d'un service (ici le driver JDBC) : uses java.sql.Driver;   // On déclare l'implémentation d'un service (ici le driver JDBC) : provides java.sql.Driver with com.mydomain.mymodule.MyDriver; }

---

a++

J'ai l'impression que Jigsaw est l'évolution la plus dangereuse de l'histoire de Java. Espérons qu'Oracle saura le maîtriser...

Pourquoi dangereuse ?


Cela va surtout être pratique pour les concepteurs de librairies, afin d'organiser le code proprement tout en pouvant cacher les classes internes et mieux gérer les dépendances (on aura une erreur au lancement de l'appli plutôt qu'un NoClassDefFoundError n'importe quand).



a++

Pour que ce projet soit vraiment profitable, il faudra aussi que bon nombre de librairies externes fasse une refonte/révision de leur code.
Je viens de faire un jdeps sur une de mes applications et cela m'a fournit quelques surprises.

Ex: avec xtsream, librairie XML :
"com.thoughtworks.xstream.converters.extended" -> "javax.swing.plaf (Full JRE)";


Je vois aussi
"org.apache.log4j.chainsaw" -> "java.awt (Full JRE)";
"org.apache.log4j.chainsaw" -> "java.awt (Full JRE)";
...

Cette application utilise en effet log4j, mais pas chainsaw. Comme exclure chainsaw et les dépendances qu'il amène ?

Sauf erreur jdeps analyse toutes les classes du jar, donc s'il trouve quelque chose lié à Swing ou AWT il va faire le lien avec.
Et de toute manière par défaut les jar "classique" seront lié avec le "full-JRE" puisqu'ils ne contiennent pas de description de module...
Mais cela ne changera pas grand chose avec ce qui est fait actuellement.


Ce n'est pas tant une révision du code qu'il faudra, mais plutôt bien séparer les fonctionnalités en module.
Remarque ca doit déjà être le cas via des package, mais vu que c'est stocké dans un seul JAR jdep prend le tout.

Du coup pour ce cas précis il faudrait définir deux modules par exemple (un pour le coeur, et un autre pour les outils graphiques par exemple).


Tiens au passage cela me fait remarquer que je ne sais pas comment seront distribué ces modules. Toujours des fichiers *.jar ???


a++

Ben le risque, c'est des régressions dans le code existant, y compris dans le code des librairies. Ca peut aller assez loin, j'ai l'impression. Dans le meilleur des cas, ça va pas aider pour les migrations vers Java 9. Dans le pire des cas, ça casse la compatibilité ascendante et ça met méchamment à mal la réputation de fiabilité de Java.

Citation:

---

Envoyé par Traroth2

Ben le risque, c'est des régressions dans le code existant, y compris dans le code des librairies. Ca peut aller assez loin, j'ai l'impression. Dans le meilleur des cas, ça va pas aider pour les migrations vers Java 9. Dans le pire des cas, ça casse la compatibilité ascendante et ça met méchamment à mal la réputation de fiabilité de Java.

---

Certes mais un moment donné, pour envisager le futur de Java , il faut bien ce débarrasser de ce qui à été mal architecturé.

C'est vrai que cette dépendance inter-lib est pesante, on ne retrouve pas ce genre de chose qui plante à l'exécution en .NET par exemple ( Bon ils sont arrivés bien après aussi...)

Y'a un truc que je suis pas sûr de bien comprendre.

Quand il est dit qu'il sera possible de générer un JRE par configuration, ça restera toujours sur la base des 3 profils "CompactX" de Java 8 ? Ou alors sera t'il possible de créer un JRE custom pour chaque appli ?

Et du coup ça va se passer comment sur une machine client, est-ce qu'il faudra embarquer notre JRE custom dans notre appli ? Si c'est le cas ne risque t'on pas de voir se cumuler les JRE custom sur une machine ?

Citation:

---

Envoyé par Traroth2

Ben le risque, c'est des régressions dans le code existant, y compris dans le code des librairies. Ca peut aller assez loin, j'ai l'impression. Dans le meilleur des cas, ça va pas aider pour les migrations vers Java 9. Dans le pire des cas, ça casse la compatibilité ascendante et ça met méchamment à mal la réputation de fiabilité de Java.

---

Si tu parles de l'API standard qui a été fortement remanié pour éviter trop de dépendance dans tous les sens... cela a déjà été fait en grosse partie dans Java 8.
Java 9 apportera surtout la possibilité de définir ces modules...

Citation:

---

Envoyé par Nico02

Quand il est dit qu'il sera possible de générer un JRE par configuration, ça restera toujours sur la base des 3 profils "CompactX" de Java 8 ? Ou alors sera t'il possible de créer un JRE custom pour chaque appli ?

---

Non c'est surtout que l'API standard sera découpé en module, et qu'il pourra exister sur certains systèmes des JREs ne comportant pas toutes les librairies.
Je pense par exemple à l'embarqué, aux TV ou aux mobiles qui n'intègrerait pas Swing/AWT, CORBA ou autres...

Les modules permettront de déterminer dès le début les dépendances., et donc de savoir si une appli peut fonctionner ou pas sur un profil.


a++

Bonjour

Citation:

---

Envoyé par adiGuba

Salut,



Attention l'exemple donné semble venir d'une vieille version.
Les mot-clefs require/export/provide prennent un 's', le versionning est laissé aux profits d'outils spécialisé...

---

L'article original date de septembre 2015. Je ne sais pas de quand date la "nouvelle" version mais les différences peuvent être dues à ça.

-----

Personnellement, je trouve que jigsaw est un peu décevant comparé à ce que propose déjà OSGi (modularisation du JDK mise à part). Pourquoi utiliser OSGi? (en anglais). Surtout pour les versions des modules : c'eut été bien de ne plus écrire de pom.xml (ou autre...). On aurait même pu digérer que la JVM ne gère pas les conflits de versions mais qu'ils nous laissent au moins les mettre sur nos modules pour qu'un outil de build auto ou un conteneur d'applications puissent faire les résolutions sans qu'on soit obligé d'indiquer les versions d'une autre manière (MANIFEST.MF, pom.xml) :(. C'est assez surprenant, surtout que, de mon point de vue, le grand succès de Maven est surtout dû à la déclaration facile des dépendances (ce qui inclut les versions des dépendances).

Yann

Citation:

---

Envoyé par yann2

L'article original date de septembre 2015. Je ne sais pas de quand date la "nouvelle" version mais les différences peuvent être dues à ça.

---

Oui le lien que je donne est tout récent (début du mois).
Mais ce n'était pas une critique juste une précision ;)


Sinon je suis plutôt d'accord concernant le versioning.
C'est dommage qu'on ne puisse pas préciser une version de manière standard (même si la gestion des dépendances auraient continuer à être géré par des outils externes spécialisés).
Je ne sais pas pourquoi ceci a été mis de coté !

Toutefois j'ai cherché un peu et cela semble toujours pris en compte dans les problèmes de la JSR : http://openjdk.java.net/projects/jig...es/#versioning
A suivre donc...


a++

AdiGuba,

Merci pour le retour. J'ai changé le tutoriel pour faire correspondre aux mots clés de la spécification.

Personnellement quand je vois les nouvelles propositions pour la prise en compte de modules, je ne suis pas du tout perdu. Cela ressemble fortement à du OSGi

Mickael

Citation:

---

Envoyé par adiGuba

Si tu parles de l'API standard qui a été fortement remanié pour éviter trop de dépendance dans tous les sens... cela a déjà été fait en grosse partie dans Java 8.
Java 9 apportera surtout la possibilité de définir ces modules...

---

Non, je parle des milliards de lignes de code Java (et ce n'est pas exagéré) qui se baladent sur toute la planète. J'imagine bien qu'Oracle va faire son possible pour que ça se passe bien pour le coeur de Java. Mais même là, le risque n'est pas absent, vu l'ampleur des changements apportés, en particulier à la JVM. C'est la plus grosse modification de la JVM depuis son lancement, non ? (et là, je mets un point d'interrogation, parce que c'est juste une impression que j'aurais du mal à étayer).

Bah sauf erreur on pourra toujours continuer à lancer les applications "comme maintenant", c'est à dire via des jar "classique" et sans contrôle des modules.
Donc la compatibilité sera assuré de ce coté là.


Je craint que le soucis soit plutôt pendant l'étape intermédiaire avec des jar "classiques" et des modules...



a++

Bonjour

J'ai cru comprendre qu'il y a quand même des inquiétudes à avoir pour les classes internes à la JRE (com.sun.* et sun.*). Je ne peux pas confirmer mais apparemment il peut y avoir un problème là dessus (en faisant une recherche rapide sur le net on trouve facilement des articles). Ça ne sera pas un problème pour nos applications mais certainement pour des frameworks ou serveur d'applications. Pour les gros frameworks qui sont bien maintenus, ça ne devrait pas poser de soucis. Pour le reste :?

Oui mais bon lorsqu'on utilise cela on fait délibérément du code pas portable basé sur des APIs interne non-documenté et sans garantie de compatibilité.
Faut pas s'étonner que cela ne fonctionne pas...

Et justement les modules permettront d'empêcher ce genre de pratique à l'avenir.



En fait c'est surtout la suppression de la classe sun.misc.Unsafe qui pose problème... mais c'est prévu en dehors du projet Jigsaw.


a++

J'ai fait quelques essais sur l'early access intégrant jigsaw : https://jdk9.java.net/jigsaw/


Le plus troublant c'est que javac indique que le package n'existe pas si l'on n'a pas déclarer le module correspondant.
C'est pas top surtout pour les classes de l'API standard, mais je suppose que les EDIs pourront gérer cela un peu mieux.




Par contre la bonne nouvelle c'est qu'il est bien possible d'associer un numéro de version au module.
La différence c'est que cela ne se fait pas dans le fichier module-info.java, mais à la création du jar via l'option --module-version.

L'information est alors accessible à l'exécution via la classe ModuleDescriptor

Code:

---

System.out.println( getClass().getModule().getDescriptor().version() );

---

C'est pas plus mal car le numéro de version peut être géré en dehors du code (ex généré automatiquement lors du build).



a++

Le système de module a été intégré dans le dernier build du JDK9 : https://blogs.oracle.com/java/entry/...ystem_in_jdk_9

L'accès aux API internes (sun.*, com.sun.*) est bien bloqué par le système de module.
Toutefois il est possible d'y accéder quand même via une option de la ligne de commande (pour la compatibilité avec des applications existantes, car l'accès à ces APIs devraient être évité).


a++

Je comprends qu'il faille trouver un moyen de réduire la taille des exécutables Java.

L'autre jour, je faisais une application Spring Boot en mode console, sans autre que le nécessaire pour qu'elle profite de l'injection de dépendance.
Bilan : un exécutable dépassant allègrement 5 Mo, dont 4 Mo pour spring-boot, spring-context et spring-core...

Sans vouloir revenir au temps de l'assembleur et de la sculpture à l'octet près, mon code n'utilise pas dans Spring plus de 300 Ko de ce qu'il propose réellement dans ses jars.
C'est embêtant de trimballer pour 3 000 classes avec soit quand on en met en œuvre que 200, transitivement.
Donc si Java 9 parvient à cela, je pense que c'est une bonne chose.

Il faudra sûrement réviser le code, avec un emploi surveillé des API reflection, je pense. Parce que même un bon éditeur de lien ne pourra pas prévoir quelles classes peut joindre des appels de cette API par des programmes leur adressant des demandes de chargement et d'invocation par des chaînes de caractères.

Par ailleurs, pour les projets Open Source, qui créent des API à disposition d'autres programmeurs, ces modules vont être une bénédiction.
Pouvoir planquer des packages dits "internes", va permettre de réduire le temps de rangement à consacrer aux packages.