Java Jigsaw ou la disparition du CLASSPATH

J’ai eu le plaisir d’assister à l’événement Devoxx 2010. Les conférences ont toutes été de bonne qualité, mais celle présentée par Mark Reinhold sur le projet Jigsaw a retenu tout particulièrement mon intérêt. En effet, l’une des conséquences de ce projet est la disparition du CLASSPATH !

Les objectifs du projet Jigsaw sont multiples:

• Améliorer significativement les performances,
• Améliorer la «scalabilité» de la plate-forme Java,
• Déprécier de l’archivage des fichiers CLASS dans des fichiers JAR

Aux grands maux, les grands remèdes. Les solutions proposées sont respectivement :

• Le chargement incrémental des modules nécessaires à l’exécution de l’application et l’optimisation du contenu des modules à l’installation.
• L’identification des modules supportés par les appareils à faible capacité.
• L’élimination du CLASSPATH et l’exploitation des packages de type RPM, DEB, SRV4, IPS.

La notion de module apparait donc en Java. Elle doit permettre :

• Un chargement rapide des fichiers CLASS au démarrage comme durant l’exécution et cela, quelque soit la plate-forme matérielle utilisée. - Utilisation de la résolution statique et optimisation du format de stockage des classes.
• La prédictibilité du chargement des classes. - Utilisation de la résolution statique.
• De fonctionner avec le système actuel. - Définition de multi-modules.
• La substitution de module pour, par exemple, charger le module correspondant à l’environnement cible (architecture matérielle, localisation, …). - Détection à l’installation et à l’exécution de la présence ou de l’absence des méthodes optionnelles.
• L’application des principes des modules à la plate-forme elle-même. - Utilisation de modules virtuels.

La résolution statique ou «static linkage» est une technique exploitée depuis 1996 par Java Card, une technologie destinée aux plates-formes très contraintes comme les cartes à puce par exemple.

Concernant l’optimisation du stockage des fichiers CLASS, la première chose qui vient à l’esprit, lorsqu’on constate que 20 à 40% de la taille des fichiers binaires Java est occupée par les pools de constantes, est leurs mutualisations au sein d’un pool au niveau des packages ou des modules. Adapter le format des fichiers CLASS à la plate-forme, comme le fait le compilateur de Google pour Android, permettra d’optimiser leurs chargements en mémoire.

Une dernière avancée majeure, dans la recherche de l’accélération du chargement des fichiers CLASS, est le déplacement de la vérification du byte code durant la phase d’installation des modules. Pour rappel, avant tout chargement de fichiers CLASS dans l’espace mémoire de la JVM, le fichier binaire est ouvert pour contrôler la cohérence du pool de constantes et la validité de toutes les séquences d’instructions assembleur. En effectuant ces vérifications une fois pour toutes lors de l’installation, on allège le mécanisme de chargement des classes.

L’estimation des gains, apportés par toutes ces optimisations, est une réduction des temps de chargement de 30 à 70%.

A propos des nouveaux modules Java,

• Les dépendances seront directement définies dans le code source Java au sein de fichiers «module-info.java». Par exemple:

 module com.foo @ 1.0.0 { requieres org.bar.lib @ 2.1-alpha; requieres edu.baz.util >= 5.2_11; }

• Plusieurs versions d’un même module pourront être présentes en mémoire.
• Ils seront gérés par les commandes «jmod» et «jpkg».
• Des dépôts de modules, équivalent aux «repositories» Maven, pourront être déclarés au sein de la JVM pour permettre le téléchargement automatique des modules nécessaires.
• Les modules Java NE seront PAS compatibles avec OSGi.

Cerise sur le gâteau, voici la vidéo intégrale de la présentation.

JSR 337.

Un point reste en suspend pour moi: comment fonctionnera le mécanisme d’isolation de la mémoire avec Jigsaw ? Mark Reinhold a indiqué, en fin de conférence, que cela sera géré, mais, sans en dire d’avantage…