Chaque mois de septembre, avec une régularité métronomique, nous disposons d’une nouvelle version de la plateforme Java. Un petit point concernant le timing est que la première version candidate du JDK 27 a été retardée de deux semaines en raison de la publication de la première mise à jour critique du correctif de sécurité (CPSU) pour le JDK. La nécessité d’un CPSU est une implication directe des modèles d’IA, tels que Claude Mythos d’Anthropic, qui deviennent bien meilleurs dans l’identification des vulnérabilités et le développement d’exploits. Si vous n’êtes pas déjà en train de réévaluer votre stratégie de correctifs pour le JDK, vous devriez certainement le faire.
Comme d’habitude, les nouvelles fonctionnalités de chaque version de Java sont principalement pilotées par un ensemble de propositions d’amélioration du JDK (JEP). Dans le JDK 27, nous avons neuf JEP, et cinq d’entre elles sont des fonctionnalités qui continuent d’être révisées dans le cadre du concept de fonctionnalités de prévisualisation et de modules d’incubation.
Commençons par ceux-là, car les changements sont intentionnellement mineurs.
Fonctionnalités d’aperçu et d’incubateur dans JDK 27
JEP 537 ramène l’API vectorielle pour un douzième incubateur record. Ce n’est pas parce que l’API présente des problèmes importants ; c’est parce qu’il s’agit d’une composante du plus grand projet Valhalla. Les auteurs de l’API ne veulent pas la finaliser tant que Valhalla n’est pas livré (plus d’informations sur Valhalla plus tard). En tant que tel, il n’y a aucun changement par rapport à la version du JDK 26.
La concurrence structurée revient pour un septième aperçu solide sous JEP 533. Cela fait partie du plus grand projet OpenJDK Loom, un ensemble de fonctionnalités visant à améliorer l’évolutivité et la fiabilité des applications multithread. Seuls des changements mineurs dans cette version, principalement dans le Joiner interface.
Les constantes paresseuses (JEP 531) reviennent pour un troisième aperçu. L’idée derrière cette fonctionnalité est l’initialisation différée et la confiance JVM. Les constantes paresseuses sont des objets porteurs de données mais sont traitées comme de vraies constantes par la JVM. Cela permet les mêmes optimisations de performances que la déclaration d’un champ final. Comparé à final Cependant, les constantes paresseuses offrent une plus grande flexibilité aux développeurs lors de leur initialisation. Il n’y a que trois petites modifications apportées à l’API dans cette version.
Une fonctionnalité qui m’intéresse particulièrement est JEP 532 : les types primitifs dans les modèles, instanceofet switch. J’ai animé une session « Java puzzlers » lors de conférences et de JUG, ce qui a conduit à des points de discussion intéressants sur la façon d’utiliser cette fonctionnalité. Le JDK 26 a renforcé certaines règles concernant la domination des modèles dans les commutateurs, mais elles sont fournies sans changement dans le JDK 27.
La dernière fonctionnalité en avant-première du JDK 27 est le codage JEP 538, PEM (Privacy-Enhanced Mail) des objets cryptographiques, qui en est désormais à sa troisième version en avant-première. Cette API code et décode les clés cryptographiques, les certificats et les listes de révocation de certificats entre les objets et le format de transport PEM largement utilisé. Cela inclut un certain nombre de modifications mineures apportées à l’API. Celui qui a retenu mon attention a été le changement dans la classe PEM primaire d’un objet normal à un enregistrement. La raison en est l’inclusion de nouveaux constructeurs qui acceptent le contenu codé en Base64 dans les tableaux d’octets.
Fonctionnalités finales du JDK 27
Passons aux fonctionnalités restantes, qui sont toutes définitives.
JEP 534 active désormais les en-têtes d’objets compacts par défaut. Bien que dans le JDK 25 en-têtes d’objets compacts aient été rendus définitifs, ils nécessitaient un indicateur de ligne de commande explicite pour les activer au moment de l’exécution. En tant que changement fondamental apporté à la JVM, ils se sont désormais révélés suffisamment stables pour constituer la configuration par défaut. L’avantage qu’ils apportent est une amélioration des performances grâce à une utilisation réduite du tas (le JEP cite une réduction de 22 % de l’espace du tas et une réduction de 8 % de l’utilisation du processeur pour le benchmark SPECjbb2015).
Un autre changement intéressant est le JEP 523, qui fait du garbage collector (GC) G1 la valeur par défaut dans toutes les situations. Depuis JDK 9, G1 est la valeur par défaut pour les applications côté serveur, mais le collecteur série reste la valeur par défaut dans les environnements aux ressources limitées (ceux dotés d’un seul processeur ou de moins de 1 792 Mo de mémoire physique). Des modifications plus récentes apportées au G1 lui permettent de fonctionner aussi bien que le collecteur série dans tous les environnements. Je soupçonne que, sur la base de ce changement, nous verrons bientôt le collecteur série obsolète et supprimé d’OpenJDK.
Une fonctionnalité impressionnante est JEP 527, échange de clés hybride post-quantique pour TLS 1.3. La cryptographie post-quantique (PQC) fait référence aux algorithmes de chiffrement et de signature numérique conçus pour rester protégés contre les futures attaques des ordinateurs quantiques. Les normes cryptographiques actuelles telles que RSA et ECC (Elliptic Curve Cryptography) s’appuient sur des problèmes mathématiques, tels que la factorisation de grands nombres, qui prennent des milliers d’années à résoudre par les ordinateurs standards. Les ordinateurs quantiques exécutant l’algorithme de Shor peuvent résoudre ces problèmes en quelques heures ou minutes. Même si les ordinateurs quantiques capables de le faire ne sont pas disponibles pour le moment, les cybercriminels récoltent déjà des données cryptées, en supposant qu’ils pourront à l’avenir les décrypter avec des ordinateurs quantiques. Cette JEP intègre des algorithmes résistants aux quantiques dans la couche de sécurité Web et réseau standard de Java (TLS 1.3).
Enfin, nous avons la rédaction des données en cours JEP 536, JFR (Java Flight Recorder). Java Flight Recorder est un framework de diagnostic à faible surcharge intégré à la JVM. Il écrit les informations d’exécution et d’application sous forme d’événements horodatés dans un fichier d’enregistrement. Les enregistrements JFR incluent généralement des événements qui capturent les arguments de ligne de commande, les valeurs des variables d’environnement et les propriétés du système, afin que vous puissiez voir comment le processus a été démarré et configuré. Ces événements peuvent contenir des données sensibles, telles que des secrets dans les arguments de ligne de commande, des jetons d’accès dans les variables d’environnement et des mots de passe dans les propriétés système. JFR va désormais supprimer ces données avant qu’elles ne quittent le processus, afin que les informations sensibles ne fuient pas. Les informations expurgées peuvent être contrôlées via des arguments de ligne de commande spécifiques.
De gros changements à venir dans le JDK 28
Alors, pourquoi le titre de cet article est-il « Le calme avant la tempête » ?
En regardant les JEP du JDK 27, les nouvelles fonctionnalités sont assez calmes, principalement des modifications incrémentielles des fonctionnalités d’aperçu et quelques petits ajouts.
Ce qui nous amène à la prochaine version, le JDK 28. Même si le JDK 27 vient de sortir, nous avons déjà une idée de certaines des JEP qui seront incluses dans le JDK 28. Au moment de la rédaction de cet article, six JEP sont ciblées. Deux de ces JEP apportent des changements attendus depuis longtemps et sont à l’origine de nombreuses discussions.
Premièrement, nous aurons enfin une API JSON en Java, quelque chose qui est en cours depuis l’introduction de JEP 128, en 2018. Cet analyseur est exceptionnellement strict et n’offre aucun mode indulgent (contrairement à d’autres API tierces comme Jackson et Gson). Nous devrons attendre et voir quels sont les commentaires de la communauté à ce sujet.
Deuxièmement, il existe la JEP 541, qui rend obsolète le port macOS/x64. Avec le passage d’Apple aux puces de classe M basées sur Arm, le port Intel pour Mac va être retiré.
Nous arrivons ensuite à la très grande nouveauté du JDK 28 : les premières vraies parties du projet Valhalla. Il existe deux JEP pour cela : JEP 401, qui correspond à des objets de valeur, et JEP 539 (notez la différence entre les nombres), qui est une initialisation de champ stricte dans la JVM.
J’attendrai que le JDK 28 soit prêt à être publié avant d’en parler en détail, mais c’est une période passionnante pour Java, avec de grands changements en cours. Restez à l’écoute!
—
Forum des nouvelles technologies offre un lieu aux leaders technologiques, y compris les fournisseurs et autres contributeurs externes, pour explorer et discuter des technologies d’entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous considérons comme importantes et du plus grand intérêt pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas de matériel marketing pour la publication et se réserve le droit de modifier tout le contenu contribué. Envoyer tout demandes de renseignements à doug_dineley@foundryco.com.
