Faut-il passer à Java 9 ?
La version 9 de Java, qui contiendra en particulier les Modules du projet Jigsaw, est de nouveau repoussée de 2 mois. L’engouement semble moindre que pour la mouture précédente. Que vont m’apporter ces Modules? Et surtout, dois-je vraiment m’y mettre?
Il est vrai que la version 8 de Java, avec ses lambdas et ses streams, avait de quoi exciter la curiosité de la communauté. Elle faisait entrer les développeurs Java dans le monde de la programmation fonctionnelle. Mark Reinhold, le grand architecte d’Oracle, compare Java 8 à un jetpack, un objet cool que tout le monde rêve d’essayer. D’après lui, Java 9 serait plutôt comparable à une ceinture de sécurité, moins cool, mais nécessaire.
Mais voyons d’abord ce qu’est un Module. On peut voir un Module comme un nouveau niveau de granularité qui vient s’insérer entre le package et le jar. Souvent, il n’y aura d’ailleurs qu’un seul Module dans un jar. Un Module a deux caractéristiques principales :
- la liste des Modules dont il dépend
- la liste des packages visibles depuis l’extérieur
Maintenance
Qu’est-ce que tout ça nous apporte? D’abord, ce niveau de granularité supplémentaire nous donne de nouveaux niveaux de visibilité. En effet, la visibilité publique peut maintenant vouloir dire 3 choses :
- visible à l’intérieur du Module seulement
- visible pour le Module ainsi que ses Modules « amis »
- visible pour le monde entier
La maintenance de l’application devrait en être simplifiée, puisque les développeurs de librairies pourront mieux contrôler les packages auxquels leurs utilisateurs auront accès. Toujours pour aider à la maintenance de nos applications, il ne sera plus possible de démarrer un programme s’il manque un Module, ou si un Module est présent en double (peut-être en deux versions différentes) dans le Module Path. Ce dernier devrait d’ailleurs remplacer le Class Path, et mettra peut-être fin au tant redouté « Jar Hell« .
Sécurité
Ne plus pouvoir mettre le même package dans deux Modules différents amène aussi une meilleure sécurité aux applications. Fini le temps où l’on pouvait modifier une classe à laquelle on n’a pas accès en plaçant une autre classe du même nom et dans le même package plus avant dans le classpath.
Dans la même veine, on notera la disparition du bootclasspath, ainsi que des répertoires d’extensions qui étaient pollués en permanence au cas où quelqu’un y aurait glissé un jar. Les nouveaux niveaux de visibilité apportent une meilleure encapsulation qui va aussi dans le sens d’une amélioration de la sécurité.
Enfin, il sera possible de restreindre l’utilisation de l’introspection sur nos Modules. Comme on peut le voir, il sera plus difficile d’accéder à des fonctionnalités interdites. Preuve en est le ban mis par Oracle sur la fameuse classe sun.misc.Unsafe qui trouvera sa nouvelle place dans un Module spécial et interdit pour le commun des mortels.
Performances
Nous avons vu les gains pour la maintenance et la sécurité, mais les gains seront aussi visibles dans le secteur des performances. En effet, la JVM va désormais construire dès son démarrage un graph de dépendance des Modules. Cela lui permettra de savoir immédiatement où chercher une nouvelle classe au chargement et devrait donner de meilleurs temps de lancement à vos applications.
De plus, le format interne des jars a été revu pour l’occasion, et l’on verra de meilleures performances à l’indexage et la décompression. Finalement, le travail de modularisation du projet Jigsaw a été appliqué à l’API java. Cela a permis de mieux découper la JVM et d’éviter de charger en mémoire des classes dont on n’a que faire. Par exemple, vous n’aurez plus de classe CORBA malencontreusement chargée alors que vous instanciez une certaine classe de l’API Swing. De ce fait, la JVM devrait être plus légère à l’utilisation.
Taille de JVM
Cette « légèreté » est d’ailleurs l’un des points importants de Java 9. Le fait que la JVM pèse aux alentours de 150Mo est l’une des raisons qui a causé la faillite de Java Webstart. Peu d’utilisateurs ont envie d’attendre le chargement d’une JVM complète avant de pouvoir utiliser une nouvelle application sur le Web. Les mêmes problèmes de taille de JVM se posent encore plus de nos jours lorsque notre application devra partager des ressources mémoire avec d’autres sur le Cloud. Et quand on essaiera de porter notre application vers l’IOT, comment tiendra-t-elle sur une machine à mémoire limitée?
C’est pour cela que Java 9 intégrera un linker qui permettra de ne livrer que les Modules dont elle a vraiment besoin. Et cela s’applique aux Modules de la JVM elle-même.
Maintenance, sécurité, performance et taille de JVM. Cela fait 4 raisons pour passer à Java 9. De plus, le chemin de migration a été prévu à l’aide de différents flags et de système de Modules automatiques, nous permettant de migrer à notre rythme dans le monde des Modules. Et tout ça sans compter les nombreuses autres fonctionnalités, telles l’API Process, JShell, le support HTTP/2, les améliorations du Garbage Collector G1, et bien d’autres. A mon avis, Java 9 sera de toute façon un pas en avant.