IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Comprendre les futures fonctionnalités modulaires de Java 9
Un tutoriel Abdelmajid Lali

Le , par Mickael Baron

0PARTAGES

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 24/03/2016 à 12:11
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++
2  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 22/03/2016 à 14:55
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...
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 22/03/2016 à 15:14
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++
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 25/03/2016 à 15:33
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 : Sélectionner tout
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++
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 29/03/2016 à 9:43
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++
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 22/03/2016 à 11:16
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/jig...aw/spec/sotms/

Un exemple plus actuel serait celui-ci :
Code : Sélectionner tout
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++
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 22/03/2016 à 15:59
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 ?
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 22/03/2016 à 16:35
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++
0  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 22/03/2016 à 16:39
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.
0  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 22/03/2016 à 19:18
Citation Envoyé par Traroth2 Voir le message
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...)
0  0