Dans cette section, nous créons, compilons et exécutons le module zoo.animal.feeding. Nous avons choisi celui-ci pour commencer car tous les autres modules en dépendent. La Figure 12.3 montre la conception de ce module. En plus du fichier module-info.java, il possède un package avec une classe à l’intérieur.
Contenu de zoo.animal.feeding
Dans les sections suivantes, nous créons, compilons, exécutons et empaquetons le module zoo.animal.feeding.
Création des fichiers
Tout d’abord, nous avons une classe très simple qui affiche une ligne dans une méthode main(). Nous savons que ce n’est pas une implémentation très complexe. Tous ces programmeurs que nous avons embauchés pourront y ajouter la logique métier. Créons donc une classe simple.
package zoo.animal.feeding;
public class Tache {
public static void main(String... args) {
System.out.println("Tous nourris !");
}
}
Ensuite vient le fichier module-info.java. C’est le plus simple possible :
module zoo.animal.feeding {
}
Il y a quelques différences clés entre une déclaration de module et une déclaration de classe Java ordinaire :
- Le fichier module-info.java doit se trouver dans le répertoire racine de votre module. Les classes Java ordinaires doivent être dans des packages.
- La déclaration de module doit utiliser le mot-clé module au lieu de class, interface ou enum.
- Le nom du module suit les règles de nommage des packages. Il inclut souvent des points (.) dans son nom. Les noms de classes et de packages ordinaires ne sont pas autorisés à avoir des tirets (-). Les noms de modules suivent la même règle.
C’est beaucoup de règles pour le fichier le plus simple possible. Il y aura beaucoup plus de règles lorsque nous développerons ce fichier plus tard dans le chapitre.
L’étape suivante consiste à s’assurer que les fichiers sont dans la bonne structure de répertoires. La Figure 12.4 montre la structure de répertoires attendue.
Structure de répertoires du module zoo.animal.feeding
En particulier, feeding est le répertoire du module, et le fichier module-info.java se trouve directement en dessous. Tout comme avec un fichier JAR ordinaire, nous avons également le package zoo.animal.feeding avec un sous-dossier par portion du nom. La classe Tache se trouve dans le sous-dossier approprié pour son package.
Notez également que nous avons créé un répertoire appelé mods au même niveau que le module. Nous l’utilisons pour stocker les artefacts du module un peu plus tard dans le chapitre. Ce répertoire peut être nommé n’importe comment, mais mods est un nom courant. Si vous suivez l’exemple de code en ligne, notez que le répertoire mods n’est pas inclus, car il est vide.
Compilation de notre premier module
Avant de pouvoir exécuter du code modulaire, nous devons le compiler. À part l’option module-path, ce code devrait vous être familier :
javac --module-path mods
-d feeding
feeding/zoo/animal/feeding/*.java feeding/module-info.java
Lorsque vous saisissez des commandes en ligne de commande, elles doivent être tapées sur une seule ligne. Nous utilisons des sauts de ligne dans le livre pour rendre les commandes plus faciles à lire et à étudier. Si vous voulez utiliser plusieurs lignes à l’invite de commande, l’approche varie selon le système d’exploitation. Linux utilise une barre oblique inverse (\) pour échapper le saut de ligne.
Pour rappel, l’option -d spécifie le répertoire où placer les fichiers de classe. La fin de la commande est une liste des fichiers .java à compiler. Vous pouvez lister les fichiers individuellement ou utiliser un caractère générique pour tous les fichiers .java d’un sous-répertoire.
La nouvelle partie est module-path. Cette option indique l’emplacement des fichiers de modules personnalisés. Dans cet exemple, module-path aurait pu être omis puisqu’il n’y a pas de dépendances. Vous pouvez considérer module-path comme remplaçant l’option classpath lorsque vous travaillez sur un programme modulaire.
Qu’en est-il du classpath ?
L’option classpath a trois formes possibles : -cp, –class-path et -classpath. Vous pouvez toujours utiliser ces options. En fait, il est courant de le faire lors de l’écriture de programmes non modulaires.
Tout comme classpath, vous pouvez utiliser une abréviation dans la commande. Les syntaxes –module-path et -p sont équivalentes. Cela signifie que nous aurions pu écrire de nombreuses autres commandes à la place de la commande précédente. Les quatre commandes suivantes montrent l’option -p :
javac -p mods -d feeding
feeding/zoo/animal/feeding/*.java feeding/*.java
javac -p mods -d feeding
feeding/zoo/animal/feeding/Tache.java feeding/module-info.java
javac -p mods -d feeding
feeding/zoo/animal/feeding/Tache.java feeding/*.java
Bien que vous puissiez utiliser celle que vous préférez, assurez-vous de pouvoir reconnaître toutes les formes valides. Le tableau 12.1 liste les options que vous devez bien connaître lors de la compilation des modules. Il existe de nombreuses autres options que vous pouvez passer à la commande javac.
| Utilisation | Abréviation | Forme longue |
|---|---|---|
| Répertoire pour les fichiers de classe | -d <dir> | n/a |
| Chemin du module | -p <path> | –module-path <path> |
Scénario du monde réel
Construction des modules
Même sans modules, il est rare d’exécuter manuellement les commandes javac et java sur un projet réel. Elles deviennent longues et compliquées très rapidement. La plupart des développeurs utilisent un outil de build comme Maven ou Gradle. Ces outils de build suggèrent des répertoires dans lesquels placer les fichiers de classe, comme target/classes.
Il est probable que la seule fois où vous devez connaître la syntaxe de ces commandes est lorsque vous passez un examen. Les concepts eux-mêmes sont utiles, quoi qu’il en soit.
Assurez-vous de mémoriser la syntaxe des commandes de module. Nous vous donnons beaucoup d’exercices pratiques sur la syntaxe pour la renforcer.
Exécution de notre premier module
Avant d’empaqueter notre module, nous devons nous assurer qu’il fonctionne en l’exécutant. Pour ce faire, nous devons apprendre la syntaxe complète. Supposons qu’il existe un module nommé livre.module. À l’intérieur de ce module se trouve un package nommé com.sybex, qui a une classe nommée OCP avec une méthode main. La Figure 12.5 montre la syntaxe pour exécuter un module. Prêtez une attention particulière à la partie livre.module/com.sybex.OCP. Il est important de se rappeler que vous spécifiez le nom du module suivi d’une barre oblique (/) suivie du nom de classe complètement qualifié.
Exécution d’un module en utilisant java
Maintenant que nous avons vu la syntaxe, nous pouvons écrire la commande pour exécuter la classe Tache dans le package zoo.animal.feeding. Dans l’exemple suivant, le nom du package et le nom du module sont identiques. Il est courant que le nom du module corresponde soit au nom complet du package, soit au début de celui-ci.
java --module-path feeding
--module zoo.animal.feeding/zoo.animal.feeding.Tache
Puisque vous avez déjà vu que –module-path utilise la forme abrégée -p, nous parions que vous ne serez pas surpris d’apprendre qu’il existe une forme abrégée de –module également. L’option courte est -m. Cela signifie que la commande suivante est équivalente :
java -p feeding
-m zoo.animal.feeding/zoo.animal.feeding.Tache
Dans ces exemples, nous avons utilisé feeding comme chemin de module car c’est là que nous avons compilé le code. Cela changera une fois que nous aurons empaqueté le module et que nous l’exécuterons.
Le tableau 12.2 liste les options que vous devez connaître pour la commande java.
| Utilisation | Abréviation | Forme longue |
|---|---|---|
| Nom du module | -m <name> | –module <name> |
| Chemin du module | -p <path> | –module-path <path> |
Empaquetage de notre premier module
Un module n’est pas très utile si nous ne pouvons l’exécuter que dans le dossier où il a été créé. Notre prochaine étape est de l’empaqueter. Assurez-vous de créer un répertoire mods avant d’exécuter cette commande :
jar -cvf mods/zoo.animal.feeding.jar -C feeding/ .
Il n’y a rien de spécifique aux modules ici. Nous empaquetons tout ce qui se trouve sous le répertoire feeding et le stockons dans un fichier JAR nommé zoo.animal.feeding.jar dans le dossier mods. Cela représente comment le JAR du module apparaîtra pour les autres codes qui souhaitent l’utiliser.
Exécutons maintenant le programme à nouveau, mais cette fois en utilisant le répertoire mods au lieu des classes en vrac :
java -p mods
-m zoo.animal.feeding/zoo.animal.feeding.Tache
Vous remarquerez peut-être que cette commande est identique à celle de la section précédente, à l’exception du répertoire. Dans l’exemple précédent, c’était feeding. Dans celui-ci, c’est le chemin du module mods. Puisque le chemin du module est utilisé, un JAR de module est exécuté.