Java 27, publié le 15 septembre, confirme une tendance désormais familière : l’API Vector reste en phase d’incubation. Cette situation devrait durer tant que les briques de Project Valhalla n’auront pas elles-mêmes atteint le stade de preview. Valhalla vise à rapprocher l’expressivité de la programmation orientée objet des performances et de la compacité des types primitifs, notamment via les value objects, dépourvus d’identité propre — donc sans en-tête ni verrou de moniteur — afin d’optimiser leur représentation en mémoire et dans les registres CPU, un point clé pour le calcul vectoriel intensif.
En attendant, Java 27 généralise plusieurs optimisations déjà attendues. La JVM HotSpot active désormais par défaut les en-têtes d’objets compacts sur les architectures 64 bits : leur taille passe de 12 à 8 octets, dont 4 réservés aux besoins futurs de Project Valhalla. Oracle annonce à la clé une réduction d’environ 15 % du nombre de cycles GC, ainsi qu’un gain pouvant atteindre 10 % sur des benchmarks de parsing JSON fortement parallèles. Ces en-têtes sont déjà utilisés en production chez Amazon sur des centaines de services, et SAP les a activés dans SapMachine, son fork d’OpenJDK.
Le ramasse-miettes G1 devient lui aussi le collecteur par défaut sur tous les environnements d’exécution. Jusqu’ici, il n’était pas activé par défaut sur les machines dotées d’un seul cœur CPU ou de moins de 1792 Mo de mémoire physique. Java 27 le rend donc universel, en misant sur un compromis jugé désormais compétitif à la fois en débit et en empreinte mémoire, tout en conservant son avantage sur les temps de pause.
Autre stabilisation importante : le masquage automatique des données sensibles dans les enregistrements JFR. Le traitement s’effectue en mémoire afin d’éviter que des secrets ne persistent dans des fichiers temporaires après un crash JVM ou ne fuitent lors d’un streaming d’événements à distance. L’option consistant à s’appuyer sur des expressions régulières a été écartée, car l’API `java.util.regex` ralentirait le démarrage de la JVM, tandis que des bibliothèques C++ pourraient lever des exceptions, ce qui est interdit dans HotSpot.
Sur le front du chiffrement, Java 27 apporte la prise en charge des échanges de clés hybrides post-quantiques pour TLS 1.3. Cette évolution s’appuie sur des fondations déjà présentes dans le JDK, notamment l’API KEM introduite dans Java 21 et l’algorithme ML-KEM ajouté dans Java 24. Trois schémas, tous décrits dans la RFC 10024, sont proposés : `X25519MLKEM768`, activé et prioritaire par défaut, ainsi que `SecP256r1MLKEM768` et `SecP384r1MLKEM1024`, tous deux optionnels et non actifs par défaut.
Le JDK intègre aussi une API dédiée à l’encodage et au décodage des objets cryptographiques vers et depuis le format PEM, standard de facto défini par la RFC 7468. Il s’agit de sa troisième préversion. Cette version ajoute notamment la prise en charge des paires de clés chiffrées, avec des méthodes capables de déchiffrer des textes PKCS#8 contenant également une clé publique, ainsi qu’une classe `CryptoException` pour signaler les échecs de traitement. Plusieurs alternatives ont été étudiées puis rejetées : l’extension de `EncodedKeySpec` via une sous-classe PEM, jugée insuffisante car incapable de couvrir certificats et listes de révocation, et l’ajout de méthodes d’encodage dans `KeyFactory` et `CertificateFactory`, écarté en raison de la complexité asymétrique des multiples représentations et formats des clés.
Java 27 marque aussi une 7e préversion de l’API de concurrence structurée. L’objectif reste de simplifier l’écriture du code multithread et d’en renforcer la robustesse en traitant des groupes de sous-tâches concurrentes comme une unité de travail atomique. Cette révision refond la gestion des timeouts et améliore le traitement des exceptions dans les joiners.
Enfin, l’API `LazyConstant` passe en troisième preview. Elle vise à mieux économiser les ressources en différant l’initialisation de données immuables. Cette version supprime les méthodes de bas niveau `isInitialized()` et `orElse()`, afin d’éviter des contournements contraires à l’esprit de l’API.