les modules. Cet article a pour objectif d’expliquer ce nouveau concept, ses raisons d’être et surtout son utilité. Ce tutoriel fait partie d’une série de trois articles qui permettront de cerner ce nouveau concept afin de l’utiliser pour plus de robustesse et maintenabilité des applications développées en Java:

1. Cet article: Modules Java: Présentation et concepts
2. Modules Java: JRE modulaire
3. Modules Java: Une application exemple – Conception
4. Modules Java: Une application exemple – Intérêts

1. La programmation orientée objet et l’encapsulation

Java s’inscrit entièrement dans la programmation orientée objet (POO). Mis à part les 8 types de données primitives et qui ont tous un correspondant objet, dans Java, tout est objet. La POO est basée sur un certain nombre de concepts parmis lesquels le concept d’encapsulation vise à favoriser la robustesse et la modularité du code. Ce concept consiste, principalement, à cacher les détails des données (champs) et des traitements (méthodes) à l’intérieur de l’objet lui même. Concrètement, cela consiste à déclarer ces détails avec les modificateurs de visibilité private ou protected. Cela consiste, par conséquent, à ne laisser accessible de l’extérieur de l’objet que le strict nécessaire à son utilisation. Cela veut dire, ne déclarer avec le modificateur public que le strict nécessaire à l’utilisation externe. Un objet d’une classe conçue en conformité avec ce principe de la POO, peut être modifié sans aucune conséquence pour les reste du code, tant qu’on ne modifie pas le format de sa partie publique. Cela dote l’application d’une grande robustesse et évolutivité au cours de son cycle de vie, car le code d’une application a toujours besoin d’être modifié pour corriger des anomalies ou faire évoluer son fonctionnement.

2. Extension de la notion d’encapsulation

Dans la pratique, il s’est avéré que la classe est d’une granularité trop faible au sein d’un logiciel pour pouvoir assurer une réutilisabilité et une robustesse suffisante. Ceci est la conséquence naturelle de la compléxité et la taille grandissantes des logiciels à construire. De nos jours, une application moyenne peut rapidement atteindre plusieurs centaines de classes. Pour cela le niveau d’abstraction de l’encapsulation gagnerait en efficacité s’il est étendu à un niveau plus élevé: Le package, qui regroupe plusieurs classes dans un seul espace de noms. Dans un package, une classe peut être déclarée:

• Avec le modificateur public: ses méthodes et ses champs publiques sont accessibles à partir des autres packages.
• Sans modificateur: N’est pas accessible à partir des autres packages.

Ceci fait du package une unité de modularisation possible d’un code logiciel. On peut considérer une bibliothèque/composant logiciel composée d’un package unique où une ou plusieurs classes publiques constituent l’interface du composant et d’autres classes non publiques chargées des détails internes à cette bibliothèque/composant. Malgrés une nette amélioration apportée par ce nouveau niveau d’abstraction, cette extension reste insuffisante, notamment pour les raisons suivantes:

• La nouvelle unité modulaire est forcément mono-package.
• Absence de règles explicites de dépendance entre packages.
• Absence de toute vérification préalable de cohérence entre unités modulaires.

Notamment, la dernière raison évoquée engendre la possibilité de conflits détéctables seulement pendant l’exécution, engendrant ainsi des erreurs d’exécution. Ce problème est connu sous le nom de JAR Hell ou l’enfer des JARs.

3. Les modules en Java 9

Les modules introduits en Java 9 portent la possibilité d’encapsulation à un niveau d’abstraction encore plus élevé. C’est au niveau physique du fichier JAR que l’encapsulation peut s’effectuer. Mais au delà de l’encapsulation, une modularisation avancée du code applicatif devient possible grâce aux caractéristiques des modules Java:

• Groupement de code applicatif sous forme d’une collection de packages de tailles quelconques.
• Le module peut contenir aussi du code natif, des fichiers de configuration et des ressources statiques.
• Visibilité externe déclarative de type exports/requires qui permet la construction facile d’un arbre de dépendance.
• Vérification, préalable à l’exécution, de la cohérence des inter-dépendances entre modules.

Concrètement, un fichier JAR/module ne diffère d’un fichier JAR classique que par l’existence à sa racine d’un fichier qui s’appelle impérativement module-info.java. Ce fichier contient une définition déclarative du module.

4. Création d’un module Java

Avec un éditeur de texte, créer le fichier Hello.java dont le contenu est:

package net.meddeb.hellomodule;
class Hello {
  public static void main(String[] args) {
    System.out.println("Hello module in world !");
  }
}

Et le fichier module-info.java dont le contenu est:

module net.meddeb.premiermodule {
  exports net.meddeb.hellomodule;
}

Ensuite, compiler le code et créer le fichier JAR du module en exécutant cette série de 3  commandes dans l’odre indiqué:

javac -d classes Hello.java module-info.java
mkdir lib
jar -c -M -f lib/notrepremiermodule.jar -C classes .

Voilà! On vient de créer notre premier module Java 9 dans le dossier lib/

• Ce module s’appelle net.meddeb.premiermodule, mais le nom peut être quelconque. Dans la pratique il vaut mieux le préfixer par un nom de domaine pour l’unicité universelle.
• Le fichier JAR qui contient le module s’appelle: notrepremiermodule.jar
• Il contient un seul package net.meddeb.hellomodule, qui contient lui-même une seule classe Hello.
• Il exporte son unique package: déclaration exports dans le fichier module-info.java

Vérifier le contenu du fichier JAR de ce module. Exécuter:

jar tvf lib/notrepremiermodule.jar

Alors, la réponse est:

   233 Wed Sep 26 21:26:36 CEST 2018 module-info.class
     0 Wed Sep 26 21:26:22 CEST 2018 net/
     0 Wed Sep 26 21:26:22 CEST 2018 net/meddeb/
     0 Wed Sep 26 21:26:22 CEST 2018 net/meddeb/hellomodule/
   450 Wed Sep 26 21:26:22 CEST 2018 net/meddeb/hellomodule/Hello.class

Maintenant, on peut exécuter la classe Hello de deux manières différentes. En tant que classe exécutable (contenant la méthode main()) dans un fichier JAR quelconque, compatibilité ascendante oblige:

java --class-path lib/notrepremiermodule.jar net.meddeb.hellomodule.Hello

On peut l’exécuter, également, en tant que classe exécutable contenue dans un module:

java --module-path lib/ -m net.meddeb.premiermodule/net.meddeb.hellomodule.Hello

Cette deuxième commande ne fonctionne qu’en JAVA 9+. Le succès de son exécution, montre que le JRE reconnait bien notre module en tant que tel. Elle ne fonctionnera pas si on enlève du  JAR le fichier module-info.class. Vous pouvez le tester, il suffi de repackager le JAR sans ce fichier.]]>