Le JDK de Java 17, qui sortira en septembre 2021, ne permettra plus l'accès aux éléments internes fortement encapsulés en implémentant la proposition JEP 403 'Strongly Encapsulate JDK Internals'

La motivation de JEP 403 est qu'au fil des ans, les développeurs de diverses bibliothèques, frameworks, outils et applications ont utilisé des éléments internes du JDK de manière à compromettre à la fois la sécurité et la maintenabilité.

Dans le JDK 9 et les versions ultérieures, tous les nouveaux éléments internes sont fortement encapsulés, ce qui limite leur accès. Cependant, pour faciliter la migration, il a été délibérément choisi de ne pas encapsuler fortement, au moment de l'exécution, les éléments internes qui existaient dans le JDK 8. Le code de bibliothèque et d'application pointé par le classpath pouvant ainsi continuer à utiliser la réflexion pour accéder aux éléments non publics des packages java.*, et tous les éléments de sun.* et d'autres packages internes, qui existaient dans JDK 8. Cet arrangement est appelé encapsulation forte détendue, et était le comportement par défaut dans JDK 9.

Une option en ligne de commande a été ajoutée pour permettre de gérer cette encapsulation forte détendue : --illegal-access. La valeur par défait étant --illegal-access=permit.

Avec JDK 16 l'option --illegal-access s'est vue attribuer deny comme valeur par défaut.

JDK 17 met un tour de vis supplémentaire et l'option --illegal-access ne permettra plus l'accès aux API internes. La liste des packages concernées peut être trouvée ici.

Grâce à cette nouvelle restriction, les développeurs qui contribuent à OpenJDK pourront mettre à jour le code interne sans casser le code existant.

Les développeurs peuvent tirer parti de l'outil JDeps , avec les plugins Maven et Gradle , pour vérifier si une base de code existante utilise des composants internes JDK.

Il est à remarquer toutefois que les packages sun.misc et sun.reflect seront toujours exportés par le module jdk.unsupported et seront toujours ouverts afin que le code puisse accéder à leurs éléments non publics par réflexion. Aucun autre package du JDK ne sera ouvert de cette manière.

Enfin il sera toujours possible d'utiliser l'option de ligne de commande --add-opens ou l'attribut Add-Opens de manifest du fichier JAR pour ouvrir des packages spécifiques.