Si vous faites du Java en production, vous connaissez ce frisson : ces objets qui n’existent que pour transporter une paire de valeurs, mais qui écrasent votre mémoire et plombent le garbage collector. Depuis des années, la communauté réclamait une solution native dans la JVM. Cette solution vient enfin de franchir une étape décisive : la JEP 401 (Value Objects) est désormais fusionnée dans la branche principale d’OpenJDK, en preview pour JDK 28.
Le 31 juillet 2026, après des mois de développement intense sur la branche Valhalla, le commit cc278dbb a scellé l’intégration. Ce n’est pas une simple proposition : c’est du code réel, compilé, reviewé par une vingtaine de contributeurs, et disponible dans les builds early-access. On fait le point.
Qu’est-ce que la JEP 401 Value Objects ?
La JEP 401 introduit le concept de value objects dans le langage Java et la JVM. Un value object, c’est un objet sans identité propre. Là où deux instances d’une classe classique sont distinctes même si leurs champs sont identiques (elles ont une identité via leur référence mémoire), deux value objects ayant les mêmes valeurs sont considérés comme égaux par construction.
Cette distinction change tout :
- Plus besoin de
equals()ethashCode()écrits à la main pour comparer le contenu - La JVM peut optimiser le stockage en mémoire (plus de pointeurs, plus de padding inutile)
- Le garbage collector a moins de travail, car ces objets peuvent être stockés directement dans les tableaux ou dans d’autres objets, sans indirection
La promesse est simple : des performances radicalement meilleures pour les types de données simples, sans sacrifier la lisibilité ni la sécurité du typage.
Une fusion historique dans OpenJDK master
La pull request principal (openjdk/jdk#31120) portée par David Simms (Oracle) a centralisé l’ensemble des changements. Pour faciliter la revue, l’équipe a découpé le travail en trois sous-PR :
- JDK-8317277 : implémentation côté langage Java (compilateur javac)
- JDK-8317278 : implémentation côté JVM (HotSpot)
- JDK-8317279 : implémentation dans la bibliothèque standard
Au total, ce sont plus de 50 contributeurs qui ont participé à l’effort, avec des reviewers de renom comme Maurizio Cimadamore, Joe Darcy, Dan Heidinga ou encore Coleen Phillimore. La PR a reçu l’approbation de 14 reviewers, un nombre qui témoigne de la complexité et de la surface couverte par le changement.
Le commit final, poussé le 31 juillet 2026, prépare le terrain pour JDK 28 où la fonctionnalité sera proposée en preview.
JEP 539 : le complément indispensable
Fusionnée simultanément, la JEP 539 (Strict Field Initialization) n’est pas un détail technique anodin. Elle impose des règles d’initialisation strictes pour les champs, garantissant qu’un value object ne puisse jamais être observé dans un état partiellement construit.
Pourquoi est-ce critique ? Parce qu’un value object n’a pas d’identité. Si un thread pouvait voir un champ à zéro pendant qu’un autre thread est en train de le construire, toute la sémantique de valeur s’effondrerait. La JEP 539 verrouille ce comportement au niveau de la JVM, rendant les value objects fiables par défaut.
Les deux JEP sont donc indissociables. L’équipe Valhalla les a développées dans la même base de code (branche valhalla/lworld), et leur intégration conjointe dans master reflète cette dépendance fonctionnelle.
Pourquoi c’est un tournant pour l’écosystème Java
Les value types étaient l’arlésienne de la JVM. Le projet Valhalla a démarré il y a près de dix ans, et beaucoup de développeurs avaient fini par douter de son aboutissement. La fusion dans master change radicalement la donne : ce n’est plus une expérimentation, c’est une fonctionnalité en route vers la GA.
Voici ce que cela va changer concrètement :
- Collections plus efficaces : un
ArrayList<Point>oùPointest un value object pourra stocker les coordonnées sans pointeurs intercalaires, avec une localité mémoire bien meilleure pour le CPU - Réduction de la pression GC : moins d’objets sur le tas signifie moins de cycles de garbage collection, donc moins de pauses
- Modélisation plus naturelle : les types comme
Complex,Money,ColorouDurationn’auront plus besoin d’être émulés via des classes immuables artisanales - Interopérabilité avec les primitives : à terme, le projet Valhalla vise à unifier le traitement des primitives et des value objects, ce que les JEP futures viendront compléter
La communauté ne s’y est pas trompée. Dès l’annonce, les développeurs ont salué une avancée qui supprime ce que beaucoup considéraient comme « le plus gros obstacle à certains types de performances » dans la JVM.
Comment tester les Value Objects dès maintenant
Si vous voulez mettre les mains dans le code, plusieurs options s’offrent à vous :
- Récupérer un build early-access de JDK 28 depuis le site jdk.java.net (les builds incluent déjà la preview)
- Compiler les sources depuis le dépôt OpenJDK en suivant le tag correspondant au commit
cc278dbb - Activer la preview dans votre projet avec les flags
--enable-previewà la compilation et à l’exécution
La syntaxe exacte est encore en cours de stabilisation, mais attendez-vous à voir apparaître un modificateur value sur les classes ou les records dans les mois qui viennent. Les builds early-access vous donneront un aperçu fidèle de ce qui arrivera dans JDK 28.
Ce qu’il faut retenir
- La JEP 401 Value Objects est fusionnée dans OpenJDK master depuis le 31 juillet 2026, en preview pour JDK 28
- Elle s’accompagne de la JEP 539 (Strict Field Initialization), indispensable à la fiabilité du modèle
- Le projet Valhalla livre enfin une brique attendue depuis près d’une décennie
- Les gains attendus portent sur la mémoire, la pression GC et la localité des données
- Les builds early-access de JDK 28 permettent déjà de tester la fonctionnalité
Vous expérimentez déjà avec les value objects ou vous suivez le projet Valhalla ? Je serais curieux d’avoir vos retours. N’hésitez pas à partager cet article ou à me contacter pour échanger sur le sujet.