Shiwen Dialogue Épisode 16 | Java 27 publié : à l'ère où l'IA écrit du code, que fait ce vieux langage ?

Ouverture : un e-mail discret et le devoir semestriel remis comme d’habitude par un langage qui approche la trentaine

Le 15 septembre, Mark Reinhold, ingénieur en chef d’OpenJDK, a envoyé un court message sur la liste de diffusion announce : JDK 27 est officiellement en disponibilité générale (GA), build 35. Du RC2 du 20 août à la version finale, aucun bug de niveau P1 n’est réapparu. Les builds OpenJDK sous licence GPLv2 sont téléchargeables le jour même sur jdk.java.net/27. En 2026, alors que les outils de programmation IA se mettent à jour presque chaque semaine, ce langage qui approche la trentaine remet son devoir tous les six mois comme d’habitude — cette fois, seulement 9 JEP, aucune nouvelle syntaxe spectaculaire, aussi discret qu’une maintenance de routine.

Mais les détails méritent qu’on s’y attarde. Parmi les 9 JEP, les deux éléments qui impactent le plus directement le portefeuille des utilisateurs ne sont justement pas de la syntaxe : le ramasse-miettes G1 devient celui par défaut dans tous les environnements (JEP 523), l’en-tête d’objet compact est activé par défaut (JEP 534) — tous deux destinés à économiser la mémoire. Parallèlement, l’échange de clés hybride post-quantique fait son entrée dans TLS 1.3 (JEP 527), un changement manifestement pensé pour dans dix ans. De l’autre côté, le filtrage par motif sur les types primitifs en est à sa 5e preview, la concurrence structurée à sa 7e preview, et la Vector API à son 12e incubateur — les uns appellent cela de la rigueur, les autres de la lenteur.

Shiwen : À l’ère où l’IA écrit du code à toute vitesse, Java sort une version comme celle-ci — quelle est ta première réaction ?

Yongliang : Ce n’est pas « Java tient-il encore le coup », c’est « ces deux choses sont enfin devenues les valeurs par défaut ». Les changements qui économisent la mémoire me touchent plus que les nouvelles syntaxes — je gère la technique dans un groupe hospitalier à Tianjin, avec des centaines de services JVM sous la main ; le tas rétrécit d’un cran, la facture maigrit d’un cran. Quant aux previews qui s’éternisent, on en reparlera tranquillement.

Shiwen : Alors allons-y franchement : écrire encore du Java à l’ère de la programmation IA, est-ce de l’archaïsme ? Le marathon des previews est-il rigueur ou traînerie ? Pourquoi les deux valeurs par défaut sont-elles l’essentiel de cette version ? Pourquoi les sociétés d’IA ne parlent-elles pas du virage post-quantique ? Et trois conseils concrets pour ceux qui restent dans l’écosystème Java.

Q1 : À l’ère de la programmation IA, écrire encore du Java, est-ce de l’archaïsme ?

Yongliang : Ce n’est pas de l’archaïsme, c’est une division du travail. Plus l’IA écrit vite, plus les machines qui exécutent ce code sont sollicitées, et ce que Java a accumulé en trente ans, c’est justement l’infrastructure qui « fait que le code ne plante pas ».

Les outils IA ont fait franchir un ordre de grandeur à la vitesse de l’écriture de code ; dans mon équipe, plus de la moitié des gens utilisent l’IA pour écrire du code, il n’y a pas à esquiver cela. Mais un fait est souvent ignoré : plus l’IA écrit, plus les machines qui font tourner ce code sont à l’ouvrage. Le code généré ne s’exécute pas tout seul : il occupe de la mémoire, il faut le récupérer, il doit tenir les tâches planifiées à deux heures du matin. Je travaille dans un groupe hospitalier à Tianjin ; l’inscription aux consultations, le paiement, les analyses — tous ces systèmes tournent en majeure partie sur la JVM, et certains ont vécu plus longtemps que la plupart des sociétés d’IA. La valeur de Java n’a jamais tenu à la nouveauté de sa syntaxe — honnêtement, sa syntaxe a toujours été de la catégorie « suffisant mais pas élégant » — mais à l’infrastructure d’exécution accumulée en trente ans : des ramasse-miettes éprouvés, des outils d’observabilité analysables ligne par ligne, une communauté où il suffit d’une recherche pour trouver une réponse quand quelque chose casse. Dès lors, la question « écrire encore du Java à l’ère de la programmation IA, est-ce de l’archaïsme ? » est elle-même mal posée. La vraie division du travail est la suivante : l’IA se charge d’écrire le code, la JVM se charge de faire en sorte qu’il ne plante pas. Le seuil pour écrire du code baisse ; le seuil pour qu’un système ne plante pas, lui, n’a jamais baissé. Pour un système appelé à fonctionner pendant quinze ans, « archaïsme » est parfois un autre nom pour « fiabilité ».

Q2 : Une fonctionnalité en preview cinq fois, une concurrence affinée en sept tours, une API couvée pendant douze versions — rigueur ou lenteur ?

Yongliang : Java et l’industrie de l’IA parient sur deux choses différentes. L’IA parie sur « mettre en ligne d’abord, corriger ensuite » ; Java parie sur « le coût d’une erreur est bien plus grand que celui d’arriver un peu plus tard ». Les deux paris sont justes, à condition que vous puissiez vous permettre de perdre.

Commençons par les enjeux des deux camps. L’industrie de l’IA parie sur « mettre en ligne d’abord, corriger ensuite » : pour un produit conversationnel, le coût d’une erreur est une mauvaise réponse, on ferme, on rouvre et c’est oublié ; donc les mises à jour hebdomadaires, voire quotidiennes, sont raisonnables. Java parie dans l’autre direction : une fois la spécification du langage figée, elle l’est pour toujours ; l’effacement de type des génériques est dénoncé depuis plus de vingt ans sans être revenu, et la querelle sur les exceptions vérifiées, commencée avec JDK 5, continue encore aujourd’hui. Pour une décision irréversible, prendre quelques années de plus est rationnel, ce n’est pas de la traînerie. Et le mécanisme de « preview » sert justement à lutter contre la lenteur — il permet à des millions d’utilisateurs en production d’essayer la fonctionnalité pour de vrai avant qu’elle ne soit figée, et leurs retours modifient directement la spécification. La concurrence structurée, affinée de la 1re à la 7e version, a justement corrigé les pièges mis au jour par les utilisateurs réels. Bien sûr, le coût est réel : le filtrage par motif sur les types primitifs que vous voudriez cette année devra attendre encore quelques versions avant d’être finalisé. Ma position est franche : si vous êtes une start-up, ce rythme vous étouffera, ne forcez pas l’intégration ; si vous maintenez un système qui doit vivre quinze ans, vous serez reconnaissant que quelqu’un prenne le temps pour vous — une fonctionnalité qui arrive trois ans plus tard vaut mieux qu’une erreur qui vous suit toute votre vie.

Q3 : Pourquoi l’essentiel de cette version n’est-il pas la nouvelle syntaxe, mais les deux valeurs par défaut qui « économisent la mémoire » ?

Yongliang : Parce que la douleur réelle des entreprises est sur la facture, pas sur la syntaxe. Parmi les 9 JEP, les deux qui pèsent le plus directement sur le portefeuille sont justement ceux qui économisent la mémoire — ce n’est absolument pas un hasard, c’est le portrait-robot des utilisateurs de ce langage qui le dicte.

Regardons d’abord la structure des versions. Java 25 est la version LTS de septembre dernier ; 27 n’est pas LTS, et la prochaine LTS devrait être JDK 29. Pour les entreprises, les montées de version massives ne se font que sur les LTS ; les nouvelles fonctionnalités de 27 ne seront donc réellement déployées en production qu’avec 29. Alors pourquoi dire que 27 est importante ? Parce qu’elle transforme en comportements par défaut deux choses qui économisent la mémoire. Premièrement, G1 devient le ramasse-miettes par défaut dans tous les environnements — auparavant, choisir un GC était une décision technique à justifier ; désormais, nul besoin de choisir, c’est ce ramasse-miettes optimisé pour les objectifs de pause qui est prêt à l’emploi pour les services à grand tas. Deuxièmement, l’en-tête d’objet compact est activé par défaut, réduisant notablement l’empreinte mémoire de l’en-tête de chaque objet Java. Ces deux fonctionnalités ne sont pas sexy, mais elles modifient directement la facture : un groupe hospitalier qui fait tourner des centaines de services JVM, en réduisant l’empreinte du tas d’un dixième (estimation personnelle, pas un chiffre officiel), économise de l’argent bien réel sur les achats de mémoire et les coûts cloud. Le sucre syntaxique réjouit les développeurs ; le petit tas réjouit les finances. Quand on a passé assez de temps en entreprise, on comprend : une raison qu’on peut inscrire dans une demande d’achat vaut bien plus qu’une raison qu’on peut afficher dans une conférence de lancement.

Q4 : L’échange de clés post-quantique entre dans TLS 1.3 — un langage historique anticipe pour dans dix ans, pourquoi les sociétés d’IA en parlent-elles si peu ?

Yongliang : Parce que les clients des deux bords ne tarifient pas « dans dix ans » de la même façon. Les données hospitalières doivent être conservées pendant des décennies, et la menace « stocker d’abord, décrypter plus tard » se concrétise dès aujourd’hui ; tandis que le cycle de vie des données de la plupart des produits IA dure moins de deux ans — la serrure n’a pas encore rouillé que le produit est déjà retiré.

Ce que fait la JEP 527, c’est utiliser, dans le handshake de TLS 1.3, à la fois un algorithme traditionnel et un algorithme résistant au quantique pour calculer chacun une part de clé, de sorte que la compromission de l’un ou l’autre n’est pas fatale. Pourquoi le faire maintenant ? Parce que l’attaque de type « stocker d’abord, attendre que les ordinateurs quantiques mûrissent, puis décrypter » se produit aujourd’hui : un attaquant intercepte votre trafic chiffré actuel, le stocke, et forcera la serrure dans dix ans. Les données médicales sont conservées sur des décennies ; un handshake dans le système d’inscription aux consultations d’aujourd’hui peut produire un texte chiffré qui aura encore une valeur juridique dans les années 2040 — pour un hôpital, c’est donc un risque à payer maintenant, pas une fable pour dans dix ans. Tandis que le cycle de vie des données de la plupart des start-ups IA dure moins de deux ans, les jeux d’entraînement sont remplacés tous les quelques mois, et le produit est retiré avant que sa serrure n’ait eu le temps de rouiller — il est naturel que personne ne se presse de parler de changer les serrures. Il ne s’agit pas de savoir qui est au-dessus de qui, mais d’échelles de temps différentes : les utilisateurs d’un langage historique budgétisent pour 2040, les clients de l’industrie IA parient qu’ils existeront encore dans six mois — chacun est rationnel, et il n’y a pas lieu de se moquer les uns des autres.

Q5 : Trois conseils concrets pour ceux qui restent dans l’écosystème Java

Yongliang : Trois, dans l’ordre : en production, ne monter que les LTS ; traiter l’économie de mémoire comme un indicateur sérieux ; laisser l’IA écrire le code, mais ne pas laisser l’IA prendre les décisions d’architecture à votre place.

Premièrement, en production, ne monter que les LTS, ne courez pas après le neuf. Java 25 est la LTS en vigueur ; 27 peut servir à tester, à lire, à faire office de radar technique pour l’équipe, mais ne le montez pas en production ; la prochaine LTS devrait être JDK 29, et c’est alors seulement que vous récupérerez d’un coup ce qui aura mûri dans 27 et 29. Le syndrome d’anxiété face aux nouvelles versions est un faux problème dans cet écosystème ; le vrai risque, ce sont les incidents de compatibilité provoqués par la course au neuf. Deuxièmement, gérez l’économie de mémoire comme un indicateur sérieux. Une fois l’en-tête d’objet compact activé par défaut, prenez une semaine pour mesurer et comparer l’empreinte du tas des services cœur (c’est un travail d’estimation, mais la direction ne sera pas mauvaise), convertissez la mémoire économisée en argent et inscrivez-le dans le bilan trimestriel — montrer au patron le retour de l’optimisation JVM sera plus utile que d’écrire dix articles techniques. Troisièmement, laissez l’IA écrire le code, ne laissez pas l’IA prendre les décisions d’architecture. Le code généré par l’IA est de plus en plus abondant, mais le choix des dépendances, le découpage des services, la circulation des données — ces décisions ont des effets qui se comptent en années, et un humain doit en porter la responsabilité. Le fait que la concurrence structurée en soit à sa 7e preview sans être finalisée montre précisément combien une décision comme le modèle de concurrence est difficile — au point de nécessiter sept tours d’affinage public avant d’oser la figer. Je fais du logiciel depuis dix-sept ans, j’ai dirigé une équipe de soixante-dix personnes, et les fossés les plus coûteux dans lesquels je suis tombé étaient tous des décisions d’architecture du type « on se dit qu’on peut faire comme ça pour commencer » — aucune n’était due à une erreur de syntaxe.

Épilogue

Shiwen : Pour finir, résumez cet épisode en une phrase ?

Yongliang : L’IA décide à quelle vitesse le code est écrit, la JVM décide à quel point le système est stable — à l’ère où l’on écrit toujours plus vite, la stabilité est elle-même un avantage compétitif.

Shiwen : Je vous offre cette phrase. Rendez-vous au prochain épisode.

[Approfondissement technique] Ce coût de l’en-tête d’objet que vous n’avez jamais écrit : comment G1 et l’en-tête d’objet compact s’y associent pour économiser

Le fil de cet épisode est « économiser la mémoire touche plus aux vraies douleurs des entreprises que la nouvelle syntaxe ». Pour les lecteurs qui veulent aller un cran plus loin, décortiquons un niveau : pourquoi deux valeurs par défaut aussi discrètes méritent-elles les deux places les plus importantes de JDK 27.

Premier niveau : que stocke l’en-tête d’objet. En Java, chaque objet, outre les champs que vous écrivez, porte un en-tête : le mark word enregistre le code de hachage, l’état du verrou, le marquage GC, plus un pointeur vers les métadonnées de classe. Vous n’avez pas écrit une seule ligne de code pour ces informations, mais chaque objet les porte.

Deuxième niveau : pourquoi ce coût est important. Sur une machine 64 bits avec pointeurs compressés activés par défaut, un en-tête d’objet occupe généralement 12 octets — plus l’objet est petit, plus la part de l’en-tête est écrasante. Un objet ne contenant que deux entiers représente 8 octets de données pour 12 octets d’en-tête : plus de la moitié de la mémoire part dans les « bagages ». Pour les services qui manipulent des millions de petits objets (caches, sessions, files de messages sont les zones les plus touchées), la part du lion dans le tas n’est pas les données, ce sont les bagages.

Troisième niveau : comment les deux JEP s’associent pour économiser. L’en-tête d’objet compact (JEP 534, activé par défaut dans cette version) recode les informations de l’en-tête et comprime notablement cette empreinte ; G1 (JEP 523, devenu la valeur par défaut dans tous les environnements) découpe le tas en régions et récupère selon des objectifs de pause, si bien que les services à grand tas n’ont plus à se torturer pour choisir un ramasse-miettes. L’un rend chaque objet plus léger, l’autre rend la gestion du tas plus fluide.

Revenons au fil de l’épisode : la nouvelle syntaxe règle « est-ce agréable d’écrire du code », l’en-tête d’objet et le ramasse-miettes règlent « la facture fait-elle mal ». Pour une entreprise, l’endroit qui fait mal n’est jamais sur le clavier.

Sources de cet épisode

Liste de diffusion announce d’OpenJDK, 2026-09-15 : Mark Reinhold, « JDK 27 General Availability » (build 35, avec la liste des 9 JEP)
jdk.java.net/27 (téléchargement des builds OpenJDK sous licence GPLv2)
Cadence semestrielle d’OpenJDK et convention de nommage LTS (au 2026-09-16, la prochaine LTS devrait être JDK 29)