Dans Eclipse, quelle est la différence entre modulepath et classpath ?

Question

Dans Eclipse, quelle est la différence entre modulepath et classpath, et lequel dois-je utiliser pour ajouter un jar dans le dossier lib ? Et pourquoi la bibliothèque système JRE apparaît-elle dans modulepath ?

Answer 1

Le système de modules a principalement l'impact suivant sur le code :

• Un paquet ne peut être accédé qu'à partir d'un seul module (les paquets imbriqués sont traités séparément, donc même si le paquet java.util est dans le module java.base le paquet java.util.logging peut être dans le module java.logging )
• Vous pouvez uniquement accéder aux champs et méthodes publics du code dans les paquets exportés d'autres modules. Ceci est vrai même avec la réflexion (c.-à-d. java.lang.reflect.AccessibleObject.setAccessible(boolean) ne fonctionne que pour le code dans le même module)

Tout le code qui est sur le classpath vit ensemble dans le module "non nommé". Tout le code sur le modulepath vit dans leurs propres modules "nommés".

Il faut distinguer deux cas :

• Si vous n'ajoutez pas un module-info.java à votre projet, celui-ci fera partie du module sans nom et pourra voir tout le code du module sans nom, ainsi que le code dans java.base et le code dans les modules dans java.se Module racine. En gros, cela signifie qu'en ce qui concerne le code sur le classpath, tout fonctionne toujours comme en Java 8, donc vous devriez simplement mettre vos dépendances sur le classpath.

• Si vous avez un module-info.java dans votre projet, votre projet sera dans son propre module nommé et ne pourra voir que le code dans java.base et d'autres modules nommés qui sont référencés à l'aide de clauses "requires" dans le module-info.java. Comme les modules nommés ne sont trouvés que via le chemin des modules, vous devez placer vos dépendances sur le classpath. Cela fonctionne même pour les jars créés avant java 9, qui auront un nom de module dérivé du nom du fichier .jar (dans ce cas, ils sont appelés module "automatique").

Le JRE se trouve toujours sur le chemin des modules, de sorte que son code interne n'est pas accessible, même à partir du code situé sur le chemin des classes.

Il existe un cas particulier : Si vous avez un module-info.java dans votre projet et que vous avez du code de test dans votre projet, vous ne voulez généralement pas mentionner les dépendances de test comme junit dans le fichier module-info.java . Il existe deux solutions pour cela :

• Créer un module de test dédié. Cela a toujours été la convention pour les projets basés sur osgi. L'inconvénient est que vous ne pouvez utiliser que l'API publique dans vos tests.

• La solution utilisée par maven : Mettez vos dépendances de test sur le classpath. Lors de la compilation du code de test, maven ajoute des options de ligne de commande qui permettent au code du module nommé de lire le module non nommé (ce qui n'est pas possible via le module-info.java).

Dans Eclipse Oxygen, la solution maven n'était pas possible, car elle n'a aucune notion du code qui est du code de test, mais cela a été mis en œuvre dans la prochaine version Eclipse Photon (4.8), qui sortira en juin. Vous pouvez d'ores et déjà travailler avec les milestone builds (complets en termes de fonctionnalités) à partir des sites suivants http://download.eclipse.org/eclipse/downloads/ . Si vous trouvez des bogues, veuillez les signaler à l'adresse suivante https://bugs.eclipse.org/bugs/ .