Oracle a publié OpenJDK 17, l'implémentation de référence de Java 17. Il s'agit d'une version avec support à long terme (LTS) qui en tant que telle bénéficiera d'moins huit ans de support. Par ailleurs oracle a indiqué que les verisons LTS arriveront désormais tous les 2 ans.

Les apports de Java 17 sont récapitulés dans la note de version. Ce sont :

• Restauration d'une sémantique à virgule flottante toujours stricte (JEP 306)
• Générateurs de nombres pseudo-aléatoires améliorés (JEP 356)
• Nouveau pipeline de rendu macOS (JEP 382)
• Port macOS/Aarch64 (JEP 391)
• Abandon de l'API Applet pour la suppression (JEP 398)
• Encapsulation forte des composants internes du JDK (JEP 403)
• Correspondance de motif (Pattern Matching) pour l'instruction switch (Aperçu) (JEP 406)
• Suppression de RMI (JEP 407)
• Classes scellées (JEP 409)
• Suppression du compilateur expérimental AOT et JIT (JEP 410)
• Dépréciation le gestionnaire de sécurité pour la suppression (JEP 411)
• API de fonction étrangère et API de mémoire (incubateur) (JEP 412)
• API vectorielle (deuxième incubateur) (JEP 414)
• Filtres de désérialisation spécifiques au contexte (JEP 415)

Regardons quelques points :

Restauration d'une sémantique à virgule flottante toujours stricte

Avec la restauration d'une sémantique à virgule flottante toujours stricte, les opérations à virgule flottante seront rendues systématiquement strictes, plutôt que d'avoir à la fois une sémantique stricte en virgule flottante (strictfp) et une sémantique en virgule flottante par défaut subtilement différente. Cela restaurera la sémantique à virgule flottante d'origine dans le langage et la VM, en faisant correspondre la sémantique avant l'introduction des modes virgule flottante strict et par défaut dans Java SE 1.2.explique Oracle.

Encapsulation forte des composants internes du JDK

En ce qui concerne l'encapsulation forte des éléments internes du JDK, 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.

Classes scellées

Les classes et interfaces scellées (sealed) restreignent les autres classes ou interfaces qui peuvent les étendre ou les implémenter. L'objectif est de permettre à l'auteur d'une classe ou d'une interface de contrôler quel code est responsable de son implémentation, et de fournir un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation d'une superclasse.

Par exemple :

sealed interface Shape
    permits Circle, Rectangle { ... }

Ici Shape déclare une interface que seules Circle et Rectangle pourront implémenter. Toute autre classe qui tenterait de le faire recevra une erreur à la compilation, ou à l'exécution pour les petits malins qui auraient tenté de générer la classe dynamiquement.  

Obtenir OpenJDK 17