Java Academy · Leçon

Migrer vers les modules

Modules automatiques et sans nom

Migrer vers les modules est une leçon Java Academy gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Java Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Java Academy comprend 4 leçons au total.

Modulariser du code existant

Peu de projets adoptent les modules dès le départ. JPMS a été conçu pour une migration progressive, en permettant au chemin de classes et au chemin des modules de coexister.

Les éléments clés sont les modules automatiques et le module sans nom.

Le module sans nom

Tout ce qui est chargé depuis le chemin de classes réside dans l’unique module sans nom. Il lit tous les autres modules et exporte tous ses paquets.

C’est le pont qui permet au code existant du chemin de classes de fonctionner.

Un module nommé ne peut pas lire le module sans nom

Une règle essentielle : un module nommé explicite ne peut pas dépendre du module sans nom. Vous ne pouvez pas écrire de directive requires pour le code du chemin de classes.

Vous migrez donc de bas en haut : convertissez d’abord la représentation de vos dépendances.

Modules automatiques

Placez un JAR simple (non modulaire) sur le chemin des modules et il devient un module automatique. Il reçoit un nom dérivé automatiquement, lit tous les autres modules et exporte tous ses paquets.

Cela permet aux modules nommés de déclarer une dépendance envers un JAR qui ne possède pas encore de module-info.

Origine du nom

Le nom d’un module automatique est dérivé selon l’ordre de préférence suivant :

L’entrée Automatic-Module-Name dans le manifeste du JAR, si elle est présente
Sinon, du nom de fichier du JAR (version supprimée, tirets remplacés par des points)

L’importance des noms stables

Les auteurs de bibliothèques devraient ajouter Automatic-Module-Name à leur manifeste avant de rendre leur code entièrement modulaire. Cela garantit un nom de module stable afin que les clauses requires des utilisateurs restent valables lors de l’arrivée du véritable module-info.

Automatic-Module-Name: com.example.json

Stratégie descendante

L’approche recommandée pour votre propre application :

Conservez les dépendances sous forme de modules automatiques sur le chemin des modules
Ajoutez d’abord un module-info.java à votre module de niveau supérieur
Déclarez des dépendances requires envers les noms de ces modules automatiques

Exemple d’étape de migration

Supposons que guava-32.jar se trouve sur le chemin des modules en tant que module automatique com.google.common. Votre module d’application peut déjà en déclarer la dépendance.

module com.example.app {
    requires com.google.common;
    exports com.example.app.api;
}

Problème des paquets scindés

Le système de modules interdit à deux modules de contenir le même paquet. Les anciennes bibliothèques qui répartissent un paquet sur plusieurs JAR provoquent des erreurs.

Corrigez le problème en fusionnant les JAR, en utilisant --patch-module ou en passant à des versions qui résolvent le conflit.

Problèmes d’accès par réflexion

Les infrastructures qui effectuent une réflexion approfondie peuvent échouer avec InaccessibleObjectException une fois votre code modularisé. Ajoutez des directives opens ou, comme pont temporaire, l’option de lancement --add-opens.

Outil jdeps utile

L’outil jdeps analyse vos JAR, signale les dépendances, repère l’utilisation d’interfaces internes du JDK et peut même générer un module-info.java candidat avec jdeps --generate-module-info.

Exécutez-le d’abord pour planifier votre migration.

Vérification rapide

Rappelez-vous comment un JAR simple acquiert une identité de module.

Récapitulatif

Vous avez appris des techniques de migration :

Le code du chemin de classes réside dans le module sans nom ; les modules nommés ne peuvent pas en dépendre
Les JAR simples placés sur le chemin des modules deviennent des modules automatiques
Définissez Automatic-Module-Name pour obtenir des noms stables
Surveillez les paquets scindés et l’accès par réflexion ; utilisez jdeps pour planifier la migration

Le cours JPMS est maintenant terminé.

Questions Fréquemment Posées

La leçon « Migrer vers les modules » est-elle gratuite ?

Oui — le texte complet de « Migrer vers les modules » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Java Academy, passe à CoddyKit PRO. Le cours Java Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Migrer vers les modules » ?

Modules automatiques et sans nom Tu pratiques Java Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Java Academy ?

Aucune expérience préalable n'est requise. Java Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Migrer vers les modules » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Java Academy ?

Oui. Chaque leçon Java Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

← Retour à Java Academy