English version available

Simon Ritter a donné une présentation sur le futur JDK 9 à QCon London.

La politique de compatibilité de Java

Il a commencé avec un fait intéressant: depuis longtemps, Java a une politique de compatibilité permanente.
Si une application utilise uniquement des API prises en charge par une version N de Java, elle devrait parfaitement fonctionner sur la version N+1, sans même devoir être recompilée.
Voilà pourquoi, à ce jour, il y a:

• 23 classes, 18 interfaces et 379 méthodes qui ont été dépréciées
• Et rien qui n’a été supprimé.

JDK 9 apporte des incompatibilités

Le JDK est devenu de plus en plus lourd au fil des années. Les choses vont changer avec la version 9.

• Un petit nombre d’API actuellement supportées sera supprimé
• La structure binaire du JRE et JDK va changer (voire les détails ci-dessous)
• Il est interdit d’utiliser le caractère underscore _ pour nommer une variable. C’est maintenant un mot-clé réservé.
• Il y aura un nouveau système de versionnage de sorte qu’il sera plus facile de faire la distinction entre les versions majeures, mineures, ou les mises à jour liées à la sécurité ; par exemple, Java 9.1.2.1. Le format de versionnage actuel est difficile à comprendre, par exemple les versions 8u51 et 8u60 ne sont pas très explicites.

La structure du JDK va changer. Le dossier JRE est supprimé, tools.jar et rt.jar ne seront plus présents, ces JARs contenaient pas mal de duplication.

Pour mieux comprendre la structure pre-JDK 9, vous pouvez lire JDK 8 and JRE File Structure.

La structure du JDK 9 est beaucoup plus propre.

JEP 260 proposal est au coeur du JDK 9 et Jigsaw.

L’idée est de rendre la plupart des API internes du JDK inaccessibles par défaut, mais en en laissant tout de même quelques-unes (celles qui sont largement utilisées et sont donc critiques) jusqu’à ce qu’elles soient remplacées.

Le but est d’encapsuler toutes les API dépréciées dans un module, et finalement de s’en débarrasser plus tard (JDK 10?).

Depuis la version 8 du JDK, un outil en ligne de commande existe pour analyser les dépendances de votre JAR ou de vos classes: jdeps. Essayez-le! Il peut être utile pour savoir si vous utilisez encore des API internes du JDK. Vous devriez éviter d’utiliser de telles dépendances, car elles peuvent être supprimées dans une future version du JDK.

Jigsaw et les modules

Nous parlons de module, mais qu’est-ce que c’est en fait?
Jigsaw apporte de la modularité au JDK. Il rend Java plus évolutif et flexible, tout en améliorant la sécurité, la maintenabilité et la performance.
Le JDK est divisé en modules, l’idée est de prendre seulement ce dont on a besoin.

Module

Un module est un regroupement de code (collection de packages), il peut également contenir:

• Du code natif
• Des ressources
• Des données de configuration

Mon premier module

Pour définir un module, vous devez créer un fichier module-info.java, qui contiendra (par exemple):

module com.company.mymodule { 
  requires com.company.myothermodule; 
  requires java.sql; 
}

Vous pouvez avoir des dépendances transitives (un peu comme dans Maven) grâce au mot-clé public.

module java.sql { 
  requires public java.logging; 
}

Cela signifie que si j’ai une dépendance sur le module java.sql, je vais avoir accès à toutes les classes incluses dans java.logging (tout du moins tous les types marqués public).

Nous avons maintenant un graphe de dépendances des modules.

Visibilité d’un package

Avec l’utilisation du mot-clé exports.

module com.company.myothermodule { 
  exports com.company.myothermodule.alpha;  
  exports com.company.myothermodule.beta; 
}

Ce qui est exporté est visible, ça ne l’est pas par défaut!

Avec Java 9 et l’arrivée des modules, nous devons redéfinir le mot-clé public. Il a maintenant plusieurs significations:

• Public à tout le monde
• Public, mais seulement à des modules particuliers
• Public, uniquement à l’intérieur d’un module

Public ne signifie plus nécessairement accessible, c’est un changement fondamental.
Vous pouvez lire la spécification de Jigsaw pour en savoir plus.

Compilation et exécution avec le « module path »

Oubliez le classpath, il y a un nouveau paramètre modulepath (ou -mp) disponible avec la commande javac / java. Sa valeur contient un ou plusieurs répertoires qui contiennent les modules nécessaires pour compiler / exécuter votre application.

Enfin, notez qu’il y aura des modules par défaut pour les fichiers JAR qui ne sont pas encore modularisés (module automatique).