new Blog( perso );

Le retrait de jigsaw de la roadmap de Java 9 avait précédé JavaOne, aussi j’ai voulu voir ce qui serait présenté lors de cette session. On commence par un rappel : le JRE, c’est 50Mb de classes dont un bon paquet de legacy que votre application n’utilisera jamais. S’ajoute à cela le « jar hell » avec des classpath comportant plusieurs dizaines de librairies.

Le but de la modularisation de Java est double : assainir le JRE et fournir un mécanisme d’approvisionnement des dépendances runtime digne de ce que proposent les OS avec les paquets rpm/deb. Jigsaw utilise une pseudo-classe module-info.java pour déclarer les classes d’un module et les règles de visibilité. Cela évite qu’une classe d’implémentation, déclarée publique nécessaire pour les appels inter-package, soit tout aussi publique pour le reste du monde et bloque l’évolution des implémentations dans les bibliothèques.

Les principes de jigsaw semblent solides, assez proches d’OSGi qui lui fait concurrence en apparence. Le second élément clé de la modularité en Java concerne le JRE lui même. Avant les travaux sur ce sujet, utiliser java.lang.* « tirait » une série de dépendances qui amenait quelques aberrations comme logging ou … corba - ce qui amuse même Mark Reinhold, qui regrette d'avoir tardé à introduire la modularité dans Java et devoir cravacher aujourd'hui pour rattrapper le temps perdu. Le diagramme des dépendance ressemble à un plat de spaghetti trop cuit, ça donne l'impression que Java 1.0 a été sorti à l'arrache, une pratique courante en informatique :)



Après un refactoring des implémentations de certaines classes, le JRE devient quelque chose de nettement plus propre qui permet de ne charger qu’un sous-ensemble du JRE pour les utilisations courantes. L'histoire ne dit pas s'ils ont fait appel à David Gageot au cours de cet exercice périlleux...



Suit une démo, c’est là qu’on commence à rigoler. Partant d’un environnement vierge, quelques commandes assez touchy permettent d’approvisionner les modules nécessaires à l’application de démo puis à la lancer … lancement qui crache avec une magnifique stacktrace bien immonde. Seconde tentative selon la « other way to do it » (c’est rassurant, il y a plusieurs façons de provisionner son JRE, on a pas fini de troller sur la "bonne façon").


Le lancement de l’appli (un remake du conference-scheduler de javaone) est alors instantané, ce qui montre bien le bénéfice de cette modularisation (la JRE de base ne fait que 10Mb). Par contre, ce crash de la démo, après un premier bide du genre lors de la keynote de dimanche, ainsi que la complexité des commandes, montrent qu’il y a encore du boulot pour obtenir une implémentation robuste et utilisable par une JRE « mainstream ».

Jigsaw est une évolution réellement intéressante de Java, qui permettra de faire de la vraie Deprecation sur les vielles classes de Java. Notre JRE contient ainsi de nombreuses classes marquées @Deprecated mais qui resteront ad vitam pour assurer la compatibilité. Avec Jigsaw, ces classes pourront être mise au placard dans un module poubelle dont aucune application moderne ne dépendra, tout en assurant le fonctionnement du code plus ancien (ou mal écrit :P). Avec les default implementation sur les interfaces, Java aura ainsi les outils pour évoluer de manière concrète sans payer sans fin pour les erreur du passé tout en préservant la compatibilité.