Système de module de plate-forme Java - Java Platform Module System
Le système de module de plate-forme Java spécifie un format de distribution pour les collections de code Java et les ressources associées. Il spécifie également un référentiel pour stocker ces collections, ou modules , et identifie comment ils peuvent être découverts, chargés et vérifiés pour leur intégrité. Il inclut des fonctionnalités telles que les espaces de noms dans le but de corriger certaines des lacunes du format JAR existant , en particulier le JAR Hell , qui peuvent entraîner des problèmes tels que des problèmes de chemin de classe et de chargement de classe.
Le système de module Java était initialement développé dans le cadre du processus communautaire Java en tant que JSR 277 et devait être publié avec Java 7.
JSR 277 plus tard a été mis en attente et Project Jigsaw a été créé pour modulariser le JDK. Cette JSR a été remplacée par JSR 376 (Java Platform Module System).
Le projet Jigsaw était à l'origine destiné à Java 7 (2011) mais a été reporté à Java 8 (2014) dans le cadre du plan B, et à nouveau reporté à une version Java 9 en 2017. Java 9 comprenant le système de module Java a été publié le 21 septembre. 2017.
Architecture
Le système de module Java implémenté dans Java 9 comprend les JEP et JSR (Java Specification Request) suivants :
- JEP 200 : Le JDK Modulaire : Définir une structure modulaire pour le JDK
- JEP 201 : Code source modulaire : réorganisez le code source JDK en modules, améliorez le système de construction pour compiler les modules et appliquez les limites des modules au moment de la construction
- JEP 220 : Images d'exécution modulaires : Restructurer les images d'exécution JDK et JRE pour accueillir les modules et améliorer les performances, la sécurité et la maintenabilité
- JEP 261 : Système de module : implémenter le système de module de plate-forme Java
- JEP 282 : L'éditeur de liens Java : créez un outil capable d'assembler et d'optimiser un ensemble de modules et leurs dépendances dans une image d'exécution personnalisée
- JSR 376 : système de module de plate-forme Java
De plus, plusieurs autres fonctionnalités JDK 9 ont été ajoutées pour faciliter la transition vers le système de modules :
- JEP 238 : fichiers JAR à versions multiples : étendez le format de fichier JAR pour permettre à plusieurs versions de fichiers de classe spécifiques à Java de coexister dans une seule archive.
- JEP 253 : Préparer les contrôles d'interface utilisateur JavaFX et les API CSS pour la modularisation : définissez des API publiques pour les fonctionnalités JavaFX qui ne sont actuellement disponibles que via des API internes et deviendraient inaccessibles en raison de la modularisation.
- JEP 260 : encapsuler la plupart des API internes : rendez la plupart des API internes du JDK inaccessibles par défaut, mais laissez quelques API internes critiques et largement utilisées accessibles, jusqu'à ce que des remplacements pris en charge existent pour toutes ou la plupart de leurs fonctionnalités.
- JEP 275 : Modular Java Application Packaging : Le packager Java va évoluer pour JDK 9, le rendant conscient des modules, permettant par exemple de packager un module et tous les modules dont il dépend.
Propriétés des modules
Les modules sont une nouvelle façon de regrouper le code. Contrairement aux fichiers Jar , les modules déclarent explicitement de quels modules ils dépendent et quels packages ils exportent. Les déclarations de dépendance explicites améliorent l'intégrité du code, en facilitant le raisonnement sur les applications volumineuses et les dépendances entre les composants logiciels.
Par exemple, la déclaration de module suivante déclare que le module com.foo.bar dépend d'un autre module com.foo.baz , et exporte les packages suivants : com.foo.bar.alpha et com.foo.bar.beta :
module com.foo.bar {
requires com.foo.baz;
exports com.foo.bar.alpha;
exports com.foo.bar.beta;
}
Les membres publics des packages com.foo.bar.alpha et com.foo.bar.beta seront accessibles par des modules dépendants. Les membres privés sont inaccessibles même par un moyen tel que la réflexion , bien que l' autorisation de facto d'un «accès illégal» dépende d'un paramètre de ligne de commande.
Contrairement au format de fichier Jar, le module décrira ces dépendances dans une déclaration de module qui sera placée dans un fichier nommé module-info.java à la racine de la hiérarchie des fichiers sources du module. Le JDK sera en mesure de vérifier les dépendances et les interactions entre les modules à la fois au moment de la compilation et de l'exécution. Le JDK lui-même a été modularisé en Java 9 .
Liens avec OSGi
Le système de module Java n'a pas l'intention de prendre en charge toutes les fonctionnalités actuellement prises en charge par la plate-forme OSGi (par exemple, le modèle de cycle de vie et le registre de services). Cependant, le système de module Java prendra en charge les fonctions qui ne sont pas prises en charge par OSGi, telles que la modularité au moment de la compilation et la prise en charge intégrée des bibliothèques natives. Quelques articles explorant comment le système de module Java et OSGi pourraient interagir ont été publiés en 2016. Ils peuvent être trouvés sur InfoQ et également sur le blog de l'Alliance OSGi.
