Discussion :

[Mickael Baron]

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.

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

[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é...

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 :

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

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++

[Traroth2]

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...

[adiGuba]

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++

[lvr]

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 ?

[adiGuba]

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++

[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.

[yann2]

Bonjour

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

[adiGuba]

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++