Les éditeurs de solutions de développement Java se montrent parfois plus efficaces que l’organisation même de Java, qui a mis longtemps avant de sortir une version modularisée du langage. Et encore dans des conditions, qui posent toujours question aujourd’hui.

Java 9 est la version modularisée du langage, ce qui sous-entend que l’on n’est plus face à ce plat de spaghettis où les composants de base (java.lang, java.util, etc) s’appelaient les uns les autres, avec la quasi-impossibilité de fabriquer des sous-ensembles cohérents du langage, dédiés à des usages limités comme les mobiles ou les capteurs.

Bien entendu, le langage lui-même est intimement lié au « run time », la machine virtuelle Java SE, censée exécuter le code issu de la nouvelle version.

Et nous sommes encore très sceptiques sur la curieuse volte-face de la plupart des éditeurs qui participaient au forum Java 9, qui en une semaine ont changé radicalement d’avis, passant d’une opposition à Java 9 tel qu’il était présenté, à un soutien ferme et résolu. Il y a quelque chose qui n’est pas clair dans cette affaire et l’obligation de montrer un front uni et « serein » devant les millions de développeurs n’explique pas tout.

Java 9, une réalité ?

Officiellement, Java 9 est une réalité depuis septembre 2017, ce qui a mis la pression sur les éditeurs qui proposent des outils de développement, les IDE et toutes sortes de produits qui gravitent autour du langage. Et il faut reconnaître que certains ont été beaucoup plus réactifs que la « maison mère », au moins pour les plus concernés d’entre eux.

Eclipse, par exemple, dont on rappelle qu’il a repris les destinées de l’API Java EE 8, ce qui là aussi, peut sembler curieux, tant Eclipse reste marqué par la présence d’IBM, est compatible avec Java 9 depuis le mois de juin et sa release Oxygen. Il faudra simplement « avertir » la machine virtuelle en ajoutant les paramètres vmargs correspondant à eclipse.ini. Attention quand même, vous pourriez avoir des problèmes avec certains types qui ne seraient pas reconnus, ceux de javafx.base, par exemple. Il y aura quelques ajustements à effectuer. Ce qui est somme toute assez normal.

Chez Apache, on est assez « zen ». La plate-forme Maven 3.7 est conforme à Java 9, mais ses concepteurs avertissent les usagers qu’il pourrait y avoir des difficultés liées à la modularité. Ant, le célèbre outil de build est par contre totalement conforme avec la version Ant 1.10.1, qui existe depuis février 2017…soit 5 mois avant que Java 9 soit finalisé. Ce que confirme le forum Ant qui précise que les options nouvelles ont été ajoutées au compilateur javac et à l’outil de test junit, qui constituent le cœur du process de publication Ant.

JetBrains pour sa part est déjà compatible avec sa version 2017.2 d’IntelliJ, l’une des quatre plates-formes les plus utilisées dans le monde Java. Cette version vous permet de construire des versions modularisées du code, avec le « module path » au lieu des classpath, les fichiers module-info.java, la complétion du code et la génération des diagrammes de modules.

Les autres acteurs du monde Java sont encore dans l’expectative.

Gradle, par exemple, n’est pas prêt et ne le sera pas avant 2018. Jenkins non plus, très utilisé dans les process de mise en production agile et n’a pas non plus donné de date précise pour disposer d’une version compatible.

Les vrais problèmes arrivent

A vrai dire nous ne sommes pas inquiets pour les nouvelles applications Java 9, pour lesquelles les plates-formes de développement seront progressivement conformes. Ce qui nous inquiète plus c’est la coexistence des deux mondes, celui de l’avant java 9 et celui de l’après.

Les fondations ne sont pas les mêmes, ce qui aura des répercussions sur les serveurs d’application. Ce qu’il ne faudrait pas, c’est qu’il y ait deux Java, l’un modulaire, l’autre pas. Ce serait sans doute mortel pour un langage pour lequel on commence d’ailleurs de plus en plus à envisager un remplaçant, avec Ceylon par exemple.