Oracle a publié la version 17 du langage de programmation Java et de la machine virtuelle. En tant que première version de support à long terme (LTS) depuis le JDK 11 en 2018, les 14 JEP de cet ensemble de fonctionnalités sont :
- 306: Restore Always-Strict Floating-Point Semantics
- 356: Enhanced Pseudo-Random Number Generators
- 382: New macOS Rendering Pipeline
- 391: macOS/AArch64 Port
- 398: Deprecate the Applet API for Removal
- 403: Strongly Encapsulate JDK Internals
- 406: Pattern Matching for switch (Preview)
- 407: Remove RMI Activation
- 409: Sealed Classes
- 410: Remove the Experimental AOT and JIT Compiler
- 411: Deprecate the Security Manager for Removal
- 412: Foreign Function & Memory API (Incubator)
- 414: Vector API (Second Incubator)
- 415: Context-Specific Deserialization Filters
La cadence des fonctionnalités pour Java 17 reste similaire aux versions précédentes avec 17 fonctionnalités en Java 16, 14 fonctionnalités en Java 15 et 16 fonctionnalités en Java 14.
Deux des JEP de l'ensemble de fonctionnalités Java 17, les JEP 403 et JEP 411, ont suscité des inquiétudes au sein de la communauté Java. Nous les examinons ici.
JEP 403: Strongly Encapsulate JDK Internals
Comme l'un des principaux objectifs de Project Jigsaw, la JEP 403 propose d'encapsuler fortement tous les éléments internes du JDK, à l'exception des API internes critiques, telles que sun.misc.Unsafe, pour améliorer la sécurité et la maintenabilité du JDK. En tant que successeur de la JEP 396, Strongly Encapsulate JDK Internals by Default, il ne sera plus possible de contourner l'encapsulation forte via l'option de ligne de commande, --illegal-access, dans Java 17. Par exemple, essayez d'utiliser cette option en attribuant la valeur permit affichera l'avertissement suivant :
$ java --illegal-access=permit {filename}.java
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit;
support was removed in 17.0
Plus de détails peuvent être trouvés dans cet article d'actualité d'InfoQ.
JEP 411: Deprecate the Security Manager for Removal
Pendant de nombreuses années, le Security Manager n'a pas été le principal moyen de sécuriser le code Java côté client et a rarement été utilisé pour sécuriser le code côté serveur. L'intention est de déprécier le Security Manager, introduit dans Java 1.0, pour suppression en conjonction avec la JEP 398, Deprecate the Applet API for Removal. Comme décrit dans la section risques et hypothèses de la JEP 411 :
Jakarta EE a plusieurs exigences sur le Security Manager. Celles-ci doivent être assouplies ou supprimées pour que les applications conformes s'exécutent sur les futures versions de Java une fois que le Security Manager est déprécié puis supprimé.
Préoccupé par le développement futur de Jakarta EE, Arjan Tijms, consultant logiciel indépendant, auteur et contributeur à 23 projets EE4J, a écrit :
Comme indiqué précédemment, la suppression du Security Manager dans Java SE aura un impact sur Jakarta EE.
Actuellement, Jakarta EE 10 ciblera Java SE 11, et ne sera donc théoriquement pas affecté par cela. Cependant, les implémentations de Jakarta EE 9.1 (comme GlassFish) fonctionnent déjà sur JDK 17 aujourd'hui et doivent faire face à des avertissements agressifs dans la console concernant la dépréciation du Security Manager. Il est donc probable que toutes les implémentations de Jakarta EE 10 seront concernées avec cela tôt ou tard.
Nous ne savons pas exactement quand le Security Manager sera effectivement supprimé, mais cela empêchera les implémentations EE de s'exécuter sur n'importe quelle version, que ce soit Java SE 18, Java SE 19, etc. Cela concerne même des artefacts de l'API, car des appels au Security Manager y ont lieu. Dans l'état actuel des choses, ces artefacts d'API ne seraient pas consommables sur la version Java SE où le Security Manager est effectivement supprimé.
Il est donc probablement bon de s'y préparer déjà dans EE 10. Une bonne première étape serait peut-être d'ajouter une déclaration d'intention selon laquelle Jakarta EE prévoit effectivement de suivre Java SE et à l'avenir de supprimer l'utilisation du Security Manager. Pour le moment, ce n'est pas tout à fait clair, et j'ai remarqué que certaines équipes ont été prudentes avant de prendre des mesures en attendant une déclaration officielle à ce sujet.
Les plans pour faire évoluer la dépréciation de Security Manager dans Java 18, vraisemblablement dans une future JEP, incluent : empêcher une application ou une bibliothèque Java d'installer dynamiquement un Security Manager à moins que l'utilisateur final n'ait explicitement choisi de l'autoriser ; et dégrader d'autres API du Security Manager afin qu'elles restent en place, mais avec des fonctionnalités limitées ou inexistantes.
Vous trouverez plus de détails dans cette article d'actualité d'InfoQ.
Java 17 est-il un verre à moitié plein ?
Plus tôt cette année, InfoQ a examiné cette prochaine version comme un "verre à moitié plein" et plus modeste que de nombreux développeurs ne l'avaient prévu. Cela est en partie dû au fait que les records (JEP 395) et les types scellés (JEP 409) ont été entièrement fournis dans Java 17, mais le pattern matching (JEP 406) est toujours en preview.
Java 18
Actuellement, seuls deux JEP sont Targeted ou Integrated pour être inclus dans Java 18 :
- JEP 400: UTF-8 by Default
- JEP 413: Code Snippets in Java API Documentation
avec une JEP supplémentaire en tant que Proposed to Target :
- JEP 417: Vector API (Third Incubator)
La JEP 400 spécifie que UTF-8 est le jeu de caractères par défaut des API Java standard pour assurer la cohérence entre toutes les implémentations, systèmes d'exploitation, paramètres régionaux et configurations.
La JEP 413 introduit la balise @snippet dans le Doclet standard d'Oracle, l'utilitaire de documentation de l'API Java bien connu qui produit la sortie au format HTML par défaut. L'objectif est de simplifier l'inclusion d'exemples de code source dans la documentation de l'API.
La date de sortie de Java 18 n'a pas encore été annoncée, mais il devrait être livré à la mi-mars 2022 selon le cadence de sortie de six mois. Les développeurs peuvent anticiper un gel des fonctionnalités à la mi-décembre 2021.
Java 17 peut être téléchargé chez Oracle maintenant, avec des binaires d'autres fournisseurs qui devraient être disponibles dans les prochains jours.