Java 27 : G1 par défaut et TLS post-quantique
Java 27 généralise le ramasse-miettes G1, active les en-têtes d'objets compacts et ajoute un échange de clés TLS post-quantique. Le point sur ses 9 JEP.
Java 27 est disponible depuis le 15 septembre 2026, date de sa mise à disposition générale selon le projet OpenJDK. Cette version compte neuf JEP (JDK Enhancement Proposals). Peu de nouveautés de syntaxe définitives, mais plusieurs changements de comportement par défaut de la JVM qui peuvent modifier la consommation mémoire et les performances d'une application sans la moindre ligne de code modifiée. Un point à connaître avant de mettre à jour une image de conteneur ou un runtime de production.
G1 devient le ramasse-miettes par défaut partout
La JEP 523 met fin à une exception ancienne. Depuis JDK 9, la JVM choisissait le ramasse-miettes Serial dans les environnements contraints : machines à un seul processeur ou disposant de moins de 1 792 Mo de mémoire. Désormais, en l'absence d'option explicite, c'est toujours G1.
Les auteurs justifient ce choix par les progrès de G1 : un débit maximal proche de celui de Serial, de meilleures latences maximales et une consommation de mémoire native ramenée à un niveau comparable. Serial n'est ni déprécié ni retiré. La JEP reconnaît que certaines applications en environnement contraint pourraient rester plus performantes avec lui : il suffit alors de le sélectionner explicitement, avec -XX:+UseSerialGC. Les petits conteneurs sont les premiers concernés.
Des en-têtes d'objets plus compacts
Autre changement par défaut, la JEP 534 active les en-têtes d'objets compacts, introduits à titre expérimental dans JDK 24 puis devenus fonctionnalité produit dans JDK 25. Sur les architectures 64 bits, ils réduisent l'en-tête de chaque objet de 96 à 64 bits.
La JEP cite des mesures sur le banc d'essai SPECjbb2015 : environ 22 % de tas en moins et 8 % de temps CPU en moins dans une configuration donnée. Ces chiffres dépendent fortement de la charge et ne garantissent pas un gain identique sur une application réelle. Pour revenir à l'ancien format, l'option -XX:-UseCompactObjectHeaders reste disponible.
Un échange de clés TLS hybride post-quantique
Avec la JEP 527, l'implémentation de TLS 1.3 du JDK ajoute trois schémas hybrides, qui combinent un échange Diffie-Hellman sur courbe elliptique et l'algorithme post-quantique ML-KEM. Le premier, X25519MLKEM768, est placé en tête de la liste de préférence par défaut : les clients TLS 1.3 le proposent donc sans modification de code.
L'objectif est de parer au risque « récolter maintenant, déchiffrer plus tard », qui consiste à enregistrer aujourd'hui des échanges chiffrés pour les casser une fois des ordinateurs quantiques disponibles. Le schéma hybride reste sûr tant que l'un des deux algorithmes n'est pas compromis. La liste peut être ajustée via la propriété système jdk.tls.namedGroups.
Le reste de la version
Les autres JEP prolongent des chantiers en cours :
- Lazy Constants (troisième préversion) ;
- types primitifs dans les motifs,
instanceofetswitch(cinquième préversion) ; - Structured Concurrency (septième préversion) ;
- encodage PEM des objets cryptographiques (troisième préversion) ;
- Vector API (douzième incubation) ;
- caviardage des données sensibles dans JFR, au sein même du processus.
Faut-il migrer ?
Java 27 est une version intermédiaire : beaucoup d'entreprises restent sur JDK 25, la dernière version à support long. Tester Java 27 en préproduction permet toutefois d'anticiper les nouveaux comportements par défaut, en surveillant surtout la mémoire et les pauses de ramasse-miettes dans les petits conteneurs. Les autres écosystèmes suivent la même logique de versions régulières, comme le montrent Python 3.15 ou Node.js 26.