Hiérarchie des chargeurs de classes dans Java 9

Depuis Java-8, je sais que la hiérarchie des chargeurs de classes est la suivante: –

Chargeur de classe d’amorçage -> Chargeur de classe d’extension -> Chargeur de classe d’application

Quel est le changement dans la hiérarchie des chargeurs de classes dans Java 9 et comment ça marche?

Le ClassLoader tel que révisé dans Java-9 stipule que:

L’exécution Java a les chargeurs de classes intégrés suivants:

  • Bootstrap class loader : le Bootstrap class loader la machine virtuelle est généralement représenté sous la forme null et n’a pas de parent.

  • Platform class loader : pour permettre la mise à niveau / le remplacement des modules définis dans le chargeur de classes de la plate-forme, et lorsque les modules mis à niveau lisent les modules définis pour des chargeurs de classes autres que le chargeur de classes de la plate-forme et ses ancêtres, le chargeur de classes de la plate-forme peut être délégué à d’autres. chargeurs de classe, le chargeur de classe d’application par exemple. En d’autres termes, les classes des modules nommés définis pour des chargeurs de classes autres que le chargeur de classes de la plate-forme et ses ancêtres peuvent être visibles du chargeur de classes de la plate-forme .

  • System class loader : Il est également appelé chargeur de classe d’application et est distinct du chargeur de classe de plate-forme. Le chargeur de classe système est généralement utilisé pour définir des classes sur le chemin de classe d’application, le chemin de module et les outils spécifiques à JDK . Le chargeur de classes de la plate-forme est un parent ou un ancêtre du chargeur de classes du système auquel toutes les classes de la plate-forme lui sont visibles.

Voici le guide de migration pour Java 9,

Nouvelles implémentations de chargeur de classe

JDK 9 conserve la hiérarchie des chargeurs de classes existant depuis la version 1.2 . Toutefois, les modifications suivantes ont été apscopes pour implémenter le système de modules:

Le chargeur de classe de l’application n’est plus une instance de URLClassLoader, mais plutôt une classe interne. Il s’agit du chargeur par défaut pour les classes de modules qui ne sont ni des modules Java SE ni des modules JDK.

Le chargeur de classe d’extension a été renommé ; c’est maintenant le chargeur de classe de la plateforme . Il est garanti que toutes les classes de la plate-forme Java SE sont visibles via le chargeur de classes de la plate-forme. En outre, il est garanti que les classes des modules normalisés dans le cadre du processus Java Community Process mais ne faisant pas partie de la plate-forme Java SE sont visibles via le chargeur de classes de la plate-forme.

Ce n’est pas parce qu’une classe est visible à travers le chargeur de classes de la plate-forme qu’elle est définie par le chargeur de classes de la plate-forme. Certaines classes de la plate-forme Java SE sont définies par le chargeur de classes de la plate-forme, tandis que d’autres sont définies par le chargeur de classes d’amorçage. Les applications ne doivent pas dépendre de quel chargeur de classe définit quelle classe de plate-forme.

Les modifications apscopes à JDK 9 peuvent avoir un impact sur le code qui crée des chargeurs de classe avec null (c’est-à-dire le chargeur de classe d’amorçage) comme chargeur de classe parent et suppose que toutes les classes de la plate-forme sont visibles par le parent. Ce code devra peut-être être modifié pour utiliser le chargeur de classes de la plate-forme en tant que parent (voir ClassLoader.getPlatformClassLoader).

Le chargeur de classes de la plateforme n’est pas une instance de URLClassLoader , mais plutôt une classe interne.

Le chargeur de classes d’amorçage est toujours intégré à la machine virtuelle Java et représenté par null dans l’API ClassLoader. Il définit les classes dans une poignée de modules critiques, tels que java.base. En conséquence, il définit beaucoup moins de classes que dans le JDK 8; les applications déployées avec -Xbootclasspath / a ou qui créent des chargeurs de classe avec la valeur null en tant que parent peuvent devoir être modifiées de la manière décrite précédemment.