Modules, services, packaging et diagnostic

Comprendre le mécanisme

Un module nomme son unité de code et déclare ses dépendances. exports rend un package accessible selon les règles du système de modules ; opens concerne notamment l’accès réflexif profond. Une classe publique n’est pas pour autant accessible depuis tout module si son package n’est pas exporté. Le mécanisme uses/provides relie consommateurs et fournisseurs de services sans imposer une instanciation concrète dans le code appelant.

Raisonner et vérifier

Compilez avec une version cible explicite et vérifiez l’exécution depuis l’artefact, pas seulement depuis l’IDE. Un JAR modulaire et un JAR classique peuvent être lancés différemment. jlink construit une image d’exécution à partir de modules disponibles ; il ne remplace pas les tests ni la validation de configuration. Documentez aussi les annotations standard et la journalisation nécessaires au diagnostic de votre projet.

Déclarer les dépendances du module

Un module nommé peut décrire les modules qu’il lit et les packages qu’il expose. Cette structure aide à définir une frontière de code plus précise qu’une simple archive contenant des classes. Un JAR sans le même contrat de module ne doit pas être supposé équivalent dans tous les modes d’exécution. Lisez la configuration effective du lancement pour savoir comment les dépendances sont résolues.

Public ne signifie pas exporté partout

Une classe public d’un package non exporté ne devient pas librement accessible à tous les modules. L’export participe à la frontière d’accès entre modules, avec les autres règles applicables. Concevez les packages d’API et d’implémentation selon les besoins des consommateurs. Un test réalisé dans un seul module peut masquer cette différence : vérifiez un consommateur séparé qui utilise réellement le contrat exporté.

Ouvrir la réflexion de manière ciblée

opens vise des usages de réflexion selon le contexte du module. Ce n’est pas la même déclaration que exports pour les accès ordinaires. Un framework peut demander une ouverture spécifique sans justifier une exposition générale de toute l’implémentation. Limitez le périmètre nécessaire et vérifiez la version ciblée. L’ouverture de code ne donne pas non plus une permission métier à l’utilisateur final du service.

Aligner compilation et runtime

Un code compilé avec un JDK récent peut utiliser une syntaxe ou une API absente du runtime ciblé. Le succès dans l’IDE ne suffit donc pas. Définissez la version de production et construisez l’artefact avec un contrat compatible. Exécutez ensuite ce livrable dans un environnement propre correspondant à la cible ; ce test couvre des hypothèses que la configuration confortable du poste peut masquer.

Le rôle exact de release et jlink

L’option --release aide à cibler une version de langage et d’API selon le compilateur, mais elle n’installe pas le runtime sur le serveur. jlink peut assembler une image d’exécution à partir de modules et de leurs dépendances. Cette image devient un artefact à maintenir et à tester. Conservez sa composition et vérifiez qu’elle contient les capacités réellement utilisées par l’application déployée.

Reproduire les dépendances résolues

Une référence flottante peut évoluer entre deux constructions. Conservez les versions résolues et le processus qui produit l’artefact afin de pouvoir comparer une panne à un contenu exact. La reproductibilité ne prouve pas l’absence de vulnérabilité ; elle permet de savoir ce qui a été construit. Une mise à jour doit donc combiner changement identifié, contrôles appropriés et vérification du comportement attendu.

Vérifier les ressources embarquées

La compilation ne prouve pas que tous les fichiers, services et ressources nécessaires sont présents au runtime. Une configuration oubliée ou un chemin dépendant du poste peut échouer après livraison. Lancez l’archive ou l’image réellement construite depuis un environnement sans les fichiers de développement. Contrôlez le parcours utile, pas seulement le démarrage du processus ou l’existence d’un fichier portant le bon nom.

Un JAR distribué n’est pas un coffre

Les ressources contenues dans une archive distribuée peuvent être inspectées. Un credential embarqué ne devient pas secret parce qu’il se trouve dans un JAR. Séparez configuration sensible et artefact public selon le mode de déploiement. Testez le contenu final et les chemins de diagnostic ; retirer un secret d’une nouvelle version ne révoque pas les copies de l’ancienne déjà diffusées.

Mesurer la bonne santé du service

Un port ouvert démontre qu’un processus écoute, pas que le parcours métier fonctionne. Le contrôle de santé doit correspondre à une garantie définie : identité de version, démarrage applicatif et dépendances utiles selon son périmètre. Évitez les mutations réelles dans ce contrôle. Un résultat vert doit rester limité à ce qui a été observé et ne pas remplacer un test d’autorisation ou de restauration.

Coordonner le retour arrière avec les données

Remplacer le JAR par une version antérieure ne restaure pas automatiquement la base ou les messages déjà publiés. Une migration peut rendre l’ancien code incompatible avec l’état courant. Définissez compatibilité, procédure de reprise et critères d’acceptation avant la bascule. Un exercice doit employer des données représentatives et vérifier les invariants, plutôt que conclure à la réversibilité parce qu’un ancien fichier existe encore.

Atelier guidé : lire, expliquer et vérifier le code

module lab.orders {
    exports lab.orders.api;
}

La déclaration de l’exercice exporte le package API du module. Elle organise l’accès prévu des consommateurs qui lisent le module, mais ne fournit pas à elle seule une ouverture générale de tous les membres privés à la réflexion profonde. Le nom du module et celui du package ont des rôles distincts, à vérifier dans un projet où le package existe réellement.

Créez un petit consommateur séparé et essayez un accès à une classe d’API puis à une classe d’implémentation non exportée. Si un outil de réflexion est nécessaire, définissez et testez l’ouverture ciblée correspondante. Construisez ensuite le livrable et lancez-le hors de l’IDE. Vous distinguerez ainsi encapsulation du code, résolution des dépendances et disponibilité effective des ressources au runtime.