Java 9 est disponible, la plateforme se met aux modules
tour d'horizon des nouveaut�s
Apr�s l'arriv�e de Java 8 et ses nombreuses fonctionnalit�s en 2014, Java 9 pointe enfin le bout de son nez ce 21 septembre 2017. Java 9 inclut plus de 80 nouveaut�s toutes d�crites dans un ensemble de JEP (Java Enhancement Proposal) disponibles � cette adresse : http://openjdk.java.net/projects/jdk9/.

� travers cette annonce, l'�quipe Java de Developpez.com va vous donner un aper�u de ce qu�apporte le JDK 9 ; voici quelques-unes de ces nouveaut�s qui pourraient avoir un impact sur votre fa�on de programmer avec Java. Nous finirons par nos avis personnels respectifs. Ensuite cela sera votre tour ;-)
La modularisation via le projet Jigsaw
La modularisation annonc�e depuis de nombreuses ann�es, plusieurs fois repouss�e, est LA grande nouveaut� de Java 9. Elle a �t� d�crite principalement dans la JEP 201. D�autres JEP sont li�es � celle-ci tant le projet de modularisation est important. L�objectif principal du syst�me des modules est de fournir un JDK qui puisse �tre structur� et de pouvoir charger seulement les modules n�cessaires. Les applications du domaine de l�Internet des Objets (IOT en anglais) sont tr�s demandeuses, car les syst�mes h�tes sont g�n�ralement limit�s en ressources mat�rielles (m�moire, CPU�). Les d�veloppeurs Java pourront donc sp�cifier les modules du JDK et des biblioth�ques tierces qui sont requis par leur application.
Sur le plan th�orique, le syst�me de module apporte �galement de nombreux autres avantages :
- une plateforme plus facilement �volutive et maintenable ;
- des gains en termes de performance et d'ex�cution puisque seuls les modules n�cessaires sont charg�s ;
- des gains en termes de s�curit�, car le principe modulaire permet de fournir le juste assez n�cessaire au syst�me. De plus, l�utilisation d�API priv�es est impossible si celles-ci ne sont pas explicitement export�es.
Comment �a fonctionne ?
Pour consid�rer une application tirant parti du syst�me de modules, un fichier module-info.java est requis � la racine de votre projet. Un exemple de contenu de fichier module-info.java est propos� ci-dessous :
1 2 3 4
| module com.developpez {
requires java.sql;
export fr.developpez.com.services;
} |
Nous remarquons l�usage de nouveaux mots cl�s comme module, requires et export. Le premier �tant utilis� pour nommer le module, le deuxi�me pour exprimer les modules n�cessaires et le troisi�me pour indiquer les packages du module qui seront visibles � l�ext�rieur. Pour le dernier point, les packages souvent nomm�s impl pourront d�sormais �tre vraiment consid�r�s comme priv�s.
Les personnes ayant une connaissance de OSGi ne seront pas surprises par la syntaxe hormis l�absence de num�ro de version. En effet dans cette premi�re version, Jigsaw a fait l�impasse sur les versions. Cet aspect est d�l�gu� aux outils de build comme Maven ou Gradle.
Bien s�r, comme toute grosse nouveaut�, il y a quelques probl�mes. On peut citer par exemple l�utilisation de la m�thode setAccessible(boolean) qui permet d�acc�der � des champs priv�s par r�flexion. Cette m�thode ne fonctionnera plus pour acc�der � un champ priv� contenu dans un module pour des raisons de s�curit� et vous obtiendrez donc une belle exception de type : IllegalAccessError. Pour r�soudre cela, il faudra � ouvrir � le module en utilisant le mot cl� open sur le package ou plus globalement sur le module (voir ci-dessous).
1 2 3 4
| module fr.developpez.com {
requires java.sql;
opens fr.developpez.com.services;
} |
ou
1 2 3 4
| open module fr.developpez.com {
requires java.sql;
exports fr.developpez.com.services;
} |
Les outils ?
Au niveau des outils, il y a eu �galement des changements. Les commandes java et javac disposent naturellement de param�tres sp�cifiques pour prendre en compte le syst�me de module. L�outil jlink (JEP 282) permet d'assembler plusieurs modules Java entre eux en tenant compte de leurs d�pendances. Le r�sultat consiste en une image sp�cifique du runtime Java (JDK ou JRE) en int�grant son application. Enfin, sans �tre exhaustif, l�outil jdeps permet de conna�tre les modules dont d�pend votre projet.
Fabriques pour les collections
La nouvelle version de Java 9 apporte de gros changements au niveau des API d�di�es aux collections. Des m�thodes statiques ont �t� ajout�es sur les interfaces de List, Set et Map pour initialiser des collections. Par ailleurs, les objets cr��s sont immutables (les attributs les contenant ne sont pas modifiables). L'objectif vis� par cette am�lioration d�crite dans la JEP 269 �tant bien s�r la cr�ation de petites collections et d'�viter une lourdeur syntaxique.
Avant Java 9, nous �tions oblig�s de faire cela :
1 2 3 4 5
| List<String> myList = new ArrayList<String>();
myList.add("Developpez.com");
myList.add("Aime");
myList.add("Java");
myList = Collections.unmodifiableList(myList); |
Il y avait bien s�r l�exception de la classe Arrays pour cr�er des listes toutes pr�tes. Malheureusement, il faut bien avouer qu�il n�est pas intuitif de faire appel � la classe Arrays pour cr�er des listes. Par ailleurs pour Set et Map, il n�y avait pas d��quivalent � la classe Arrays.
Avec Java 9, la cr�ation devient plus simple.
List<String> newList = List.of("Developpez.com", "Aime", "Java")
API pour la gestion des processus
Cette am�lioration, d�crite dans la JEP 102 permet � Java de mieux coexister avec le syst�me. Initialement le d�veloppeur Java utilisait l�API Runtime.getRuntime().exec() puis avec Java 5 est apparue l�API ProcessBuilder. Malheureusement, il n��tait pas possible de conna�tre le PID du processus courant, conna�tre les sous-processus, d�truire des processus ou obtenir d�autres informations comme les param�tres d�ex�cution. Avec Java 9, les choses ont �volu� dans le bon sens avec des nouvelles classes comme ProcessHandle et des ajouts dans la classe Process.
Pour r�cup�rer le processus courant :
System.out.println(ProcessHandle.current())
Pour afficher le PID et les informations de la ligne de commande de tous les processus :
1 2 3 4
| ProcessHandle.allProcesses().forEach(p -> System.out.println(p.getPid() + " " + p.info().commandLine()));
1 Optional[/usr/lib/jvm/java-9-openjdk-amd64/bin/jshell -v]
45 Optional[/usr/lib/jvm/java-9-openjdk-amd64/bin/java -agentlib:... jdk.jshell.execution.RemoteExecutionControl 34065]
137 Optional[/usr/bin/sleep 1h] |
Multi-release des fichiers JAR
Le format du fichier JAR �volue. Celui-ci permet de g�rer plusieurs impl�mentations d'une m�me classe au sein d'une archive unique. Avant Java 9, il �tait donc impossible de g�rer plusieurs versions d�une m�me biblioth�que au sein d�une m�me archive.
Il �tait important d'apporter une solution pour assurer la compatibilit� descendante, car Java 9 int�gre de nouvelles API permettant de coder diff�remment . � l'ex�cution, la bonne version de la classe sera charg�e automatiquement en fonction de la version de Java utilis�. Cette solution est d�crite dans la JEP 238, elle est appel�e Multi-Release JAR (MR JAR pour les intimes).
Si on consid�re deux classes Foo et Bar. La seconde contient deux impl�mentations une pour Java 9 et une autre pour toutes les versions ant�rieures � Java 9. La structure du JAR sera la suivante :
1 2 3 4 5 6 7 8
| JAR root
- Foo.class
- Bar.class
+ META-INF
- MANIFEST.MF
+ versions
+ 9
- Bar.class |
Comme on peut constater la racine (JAR root) n'�volue pas et Foo.class et Bar.class seront utilis�es par toutes les versions de Java ne supportant pas MR JAR. Au contraire Foo.class et Bar.class localis�e dans META-INF/versions/9/Bar.class seront utilis�es pour la version 9 de Java.
Cette fonctionnalit� a demand� des am�liorations au niveau des outils de compilation et d'analyse. Les outils du JDK (javac, javap, jdeps...) ont �t� bien entendu impact�s. Les outils de build comme Maven ou Gradle ont d� s'adapter pour la construction de cette nouvelle structure de JAR. Sur le papier tout fonctionne pour preuve dans ce d�p�t GIT o� des tests ont �t� r�alis�s.
Un shell Java : REPL jShell
De nombreux langages sont actuellement tr�s populaires gr�ce � leur simplicit� pour l�apprentissage ; � titre d�exemple le langage Python. Cette simplicit� est en partie due � la pr�sence d�une impl�mentation appel�e REPL (Read Evaluate Print Loop). Gr�ce � ce mode de fonctionnement bas� sur une boucle, l�interpr�teur :
- Lit une expression (le R pour Read) ;
- �value une expression (le E pour Evaluate) ;
- Imprime sur la sortie standard (le P pour Print) ;
- Recommence (le L pour Loop).
Pour pallier ce manque, la version Java 9 offre un REPL appel� JShell (JEP 222) permettant une programmation interactive. JShell interpr�te directement des expressions sans avoir besoin qu�elles soient envelopp�es dans une classe ou une m�thode.
Outre l�aspect apprentissage, JShell pourra �tre utilis� pour tester du code rapidement en quelques lignes de code. Par exemple, v�rifier si un service web est pr�sent ou tester des agents de placement pour JavaFX. Il est �galement pr�vu de pouvoir int�grer JShell directement dans du code Java. On peut m�me envisager une alternative aux bons vieux scripts Bash et pourquoi pas des langages de script de la JVM comme Groovy.
Meilleure gestion du deprecated
L�annotation @Deprecated a �t� �toff�e par deux attributs : l�un de type String since et l�autre de type boolean forRemoval (JEP 277). L�attribut since permet de pr�ciser � partir de quand l�API a �t� annot�e par @Deprecated et forRemoval pr�cise que l�API en question risque d��tre supprim�e. Nous montrons ci-dessous un exemple de classe qui pr�cise que cette API a �t� annot�e @Deprecated depuis la version 2.5 et qu�elle n�est pas pr�vue pour �tre supprim�e.
1 2 3 4
| @Deprecated(since="2.5" forRemoval=false)
public class MaClassAMoi {
} |
Moteur de rendu Marlin
La JEP 265 a permis l�int�gration d�un nouveau moteur de rendu Marlin permettant aux bo�tes � outils Java (Java2D et JavaFX) d'�tre plus rapides. Pr�c�demment les moteurs de rendu Pisces et Ductus �taient utilis�s (Oracle JDK). Comme le moteur de rendu Marlin surpasse en termes de performance ces deux moteurs historiques (2006 et 1998), l'�quipe de l'OpenJDK 2D a d�cid� de l'utiliser par d�faut dans l'OpenJDK 9 et Oracle de son c�t� a fait de m�me pour Oracle JDK9 pour se d�barrasser � terme de Ductus.
Sur le graphique ci-dessous, on remarque que les r�sultats obtenus par le moteur de rendu Marlin sont toujours plus efficaces que les autres rendus. On atteint parfois des ratios de l'ordre de 650 %.

MarlinFX a �t� finalement int�gr� en d�cembre 2016 (� la derni�re minute), mais il reste d�sactiv� par d�faut dans JDK 9 (Java Pisces ou Native Pisces restent utilis�s). L��quipe Java de Developpez.com a pu r�aliser une interview de Laurent Bourg�s, l�auteur principal de cette fonctionnalit� : https://java.developpez.com/interview/laurent-bourges/
Am�liorations en vrac
Les nouveaut�s de Java 9 sont nombreuses. Nous aurions aussi pu citer les points suivants :
- Stream : de nouvelles m�thodes ont �t� ajout�es dans les classes Stream et Collectors ;
- Concurrence (JEP 266) : Java 9 est d�sormais un langage r�actif dans le sens o� une impl�mentation des Reactive Streams a �t� propos�e. La nouvelle classe Flow propose trois interfaces int�gr�es pour le producteur (Publisher), consommateur (Subscriber) et une derni�re pour la connexion entre le producteur et le consommateur ;
- une nouvelle JavaDoc estampill�e HTML 5 avec la possibilit� de rechercher du contenu dans une zone de texte. C�est d�j� une grosse �volution. Malheureusement, la recherche fulltext n�existe pas. Par ailleurs, les frames oldschool sont toujours pr�sentes ;
- un vrai client HTTP/2 (JEP 110) ;
- G1, le garbage collector par d�faut (JEP 248). Le garbage collector G1 est par d�faut sur les architectures 32 et 64 bits. Il remplacera Parallel GC avec une approche plus int�ressante pour les utilisateurs, car il diminuera les latences et son impact sur les ressources ;
- Milling Project Coin (JEP 213). Ce projet a trait � de nombreuses �volutions de la syntaxe de Java. On notera la possibilit� d�avoir des m�thodes priv�es dans les interfaces afin de mutualiser du code utilis� dans les m�thodes par d�faut. On notera aussi la possibilit� d�utiliser des variables finales dans le bloc Try-With-Resources ;
- meilleure performance pour les cha�nes de caract�res propos�es dans JEP 254, JEP 250 et JEP 280 ;
- InputStream : trois nouvelles m�thodes utilitaires ont �t� ajout�es dans la classe InputStream. readAllBytes() pour lire tout un flux, readNBytes() pour lire une portion d'un flux et transferTo() pour directement envoyer un flux d'entr�e vers un flux de sortie.
Les avis
Nous avons demand� aux membres de l��quipe Java de donner leur avis concernant cette nouvelle version de Java. Que pensent-ils de cette version, quelles nouveaut�s ont-ils pr�f�r�es et celles qu'ils trouvent d�cevantes ?
Avis 1 : Mickael Baron, responsable Java sur Developpez.com
On parle de Java 9 depuis longtemps. Cela se traduit par de nombreux articles et de pr�sentations sur le sujet. Jigsaw LA fonctionnalit� majeure de Java 9 est souvent pr�sent�e. Dans la plupart des cas, j�ai l�impression que le retour sur cette fonctionnalit� est souvent n�gatif. D�une part, elle inqui�te par le risque que les d�veloppements r�alis�s avant Java 9 ne fonctionnent plus et d�autre part, elle inqui�te par le risque que les outils de l��cosyst�me Java (Maven, Gradle, IDE�) ne soient pas du tout pr�ts � ce grand changement. Je pense qu�il faudra beaucoup de temps pour que cette fonctionnalit� arrive � percer, un peu comme les g�n�riques de Java 5 � l��poque.
De mon c�t�, la nouveaut� pr�f�r�e reste REPL. C�est d�j� un bon d�but, on peut facilement tester sans avoir � passer par la phase de compilation et d�ex�cution. Toutes les exp�rimentations faites pour la pr�paration de cette news ont �t� faites via ce REPL. Par contre, fournir une fen�tre AWT pour l��dition ce n�est pas terrible. Il aurait mieux valu se baser sur un �diteur du syst�me par d�faut.
La plus d�cevante c�est Jigsaw, non pas sur l�aspect technique, mais plus sur la mauvaise image de Java qu�elle a pu engendrer. Il ne faut pas oublier que la sortie de Java 9 a �t� repouss�e � cause de cette fonctionnalit�.
Avis 2 : Robin56, responsable Java sur Developpez.com
Comme Micka�l, quand on me parle Java 9, je pense modularit� et donc je pense Jigsaw. Son intention est louable. L� o� certaines versions ne r�volutionnaient vraiment pas l��cosyst�me Java, je pense que ce n�est pas du tout le cas de l�arriv�e de Java 9. Ceci va bousculer nos habitudes et aussi l��cosyst�me en g�n�ral. On peut d�j� remarquer les IDE et les outils de builds comme Maven devoir s�adapter � ces avanc�es.
Revers de la m�daille, je crains aussi la mont�e en version sur Java 9. J�ai bien peur qu�elle se fasse dans la douleur. Rien que le planning de livraison de Java 9 t�moigne des impacts de Jigsaw. Son retard de plusieurs mois prouve que cette �volution a des impacts majeurs sur Java. Gare aux projets qui vont migrer en Java 9, je crains qu�ils essuient les pl�tres.
Dans tous les cas, la fonctionnalit� que j�attends de voir avec l�arriv�e de Java 9 est clairement le projet Jigsaw.
Avis 3 : bouye, r�dacteur et mod�rateur Java sur Developpez.com
Mon avis rejoint celui de Mickael concernant les soucis engendr�s par Jigsaw et de Robin56 pour le besoin de tout l'�cosyst�me Java de s'adapter � ce nouveau mode de fonctionnement. Bien que n'�tant pas un grand utilisateur de Maven, Graddle et co (surtout compte tenu des limitations de mon environnement de travail pro) je reconnais que ces outils sont d�sormais pr�dominants dans le monde Java et que le nouveau venu Jigsaw semble mal s'int�grer � l'existant. Je pense attendre que les IDE et outils soient un peu plus matures avant de tenter de porter mes projets vers le JDK9... ou, si je m'y lance, le premier jet sera sans doute sans support des modules.
� vous de jouer !!
Et vous :
- Que pensez-vous de l�arriv�e de Java 9 sur le march� ?
- Quelles sont les �volutions o� vous avez le plus d�attentes ?
T�l�charger la nouvelle version de Java
Partager