Dev
Pourquoi Java 26 marque une étape importante dans l’évolution de la JVM
Par La rédaction, publié le 08 mai 2026
Java est un langage vivant. Six mois après la LTS Java 25, Java 26 poursuit le travail de fond engagé sur la plateforme : clarifier les garanties du langage, réduire la dette historique et optimiser l’exécution. Entre JVM, garbage collection, sécurité cryptographique, concurrence structurée et pattern matching, cette version intermédiaire prépare les évolutions majeures à venir.
De Arthur Murillo, Ingénieur Concepteur Développeur, chez SQLI
Java 26 arrive six mois après Java 25, dernière version LTS (Long-Term Support). Fidèle au rythme d’évolution semestriel de la plateforme, cette nouvelle release poursuit la modernisation du langage et de la JVM à travers une dizaine de JEP (Java Enhancement Proposals) qui touchent aussi bien aux fondations du langage qu’aux performances d’exécution. Parmi les évolutions les plus marquantes figurent le renforcement de la sémantique du mot-clé final, la suppression définitive de l’API Applet, plusieurs optimisations majeures du runtime et du garbage collector, ainsi que l’arrivée du support natif de HTTP/3 dans le client HTTP de Java.
Avec Java 26, l’écosystème poursuit une stratégie désormais bien établie : consolider la robustesse historique de la plateforme tout en préparant les prochaines grandes évolutions du langage et de la JVM.
Java 26 : les nouvelles fonctionnalités
JEP 500 : prepare to make final mean final
Java 26 referme une porte laissée ouverte depuis les débuts du langage. En effet, dans les versions précédentes, un attribut déclaré final, c’est-à-dire non-modifiable après son initialisation, pouvait toujours être modifié lors de l’éxécution du programme. Le mécanisme de réflexion permettait en réalité de contourner cette restriction, via la classe java.lang.reflect.Field :
Cette JEP propose pour le moment un warning au runtime afin de préparer les développeurs à la future Exception qui empêchera ce code d’être exécutable.
JEP 504 : remove the applet API
Java 26 enterre définitivement toute une ère avec la suppression de l’API Applet, qui permettait d’exécuter du code Java dans un navigateur web. Cette technologie, autrefois très populaire, est devenue dépréciée depuis Java 9 et était candidate à la suppression depuis Java 17.
À ce jour, plus aucun navigateur n’est compatible avec cette technologie, et la JEP s’inscrit dans une volonté de faire le ménage dans les API historiques du langage.
Les classes supprimées incluent notamment :
JEP 516 : Ahead-Of-Time object caching with any GC
Java 26 améliore le mécanisme de cache AOT (Ahead-Of-Time) des objets en le rendant compatible avec n’importe quel Garbage Collector.
Les objets en cache peuvent maintenant être chargés séquentiellement dans un format générique et agnostique du Garbage Collector, pour maximiser la compatibilité et les performances.
À ce jour, par défaut, les objets sont stockés dans le cache avec une adresse mémoire (par exemple 0x4002045278). Un format générique consiste à stocker plutôt les objets avec un index logique (par exemple 5). Cet index sera ensuite résolu en adresse au moment de charger le cache.
La JVM (Java Virtual Machine) applique une stratégie ou l’autre selon les situations (démarrage à chaud, à froid…) pour optimiser ses performances.
JEP 517 : HTTP/3 for the HTTP client API
Java 26 devient compatible avec le protocole HTTP/3, dernière évolution du protocole HTTP. Ce protocole utilise QUIC, qui offre notamment des améliorations en termes de latence et de performance, ainsi qu’une meilleure sécurité (connexion chiffrée par défaut).
Le HttpClient historique de Java n’était pas compatible avec ce protocole. Avec cette version, il devient possible d’indiquer dans le constructeur du client, ou dans une requête individuelle, que l’on souhaite utiliser HTTP/3.
JEP 522 : G1 GC – optimisation du Garbage Collector G1
Java 26 propose une amélioration du garbage collector G1.
Le garbage collector « Garbage-First » (G1), qui est celui par défaut dans la JVM HotSpot, est conçu pour équilibrer la latence et le débit. Cependant, cette recherche d’équilibre peut parfois avoir un impact sur les performances de l’application par rapport à d’autres collecteurs comme Parallel et Serial.
Cette version réduit la synchronisation entre les threads de l’application et ceux du garbage collector, en simplifiant les opérations d’écriture dans la Card table, une structure de données interne au garbage collector qui sert à traquer les références intergénérationnelles des objets. Ainsi, pour le Garbage Collector G1, la latence est réduite et le débit est augmenté.
Les fonctionnalités en preview ou en incubation
Comme souvent dans les versions intermédiaires du JDK, Java 26 introduit également plusieurs fonctionnalités en preview ou en incubation.
Ces mécanismes permettent à la communauté de tester les évolutions avant leur stabilisation définitive.
Pour rappel : afin de les activer, le programme doit être compilé avec des options spécifiques (par exemple, –enable-preview).
JEP 524 : PEM encodings of cryptographic objects
🟡 En évolution active
Cette JEP, déjà introduite en preview dans Java 25, continue d’évoluer.
Son objectif est de proposer une API plus concise et moderne pour manipuler les clés cryptographiques et certificats au format PEM (Privacy-Enhanced Mail).
Cette nouvelle version ajoute notamment :
JEP 525 : structured concurrency
🟢Stable
La Structured Concurrency poursuit sa maturation après plusieurs itérations successives.
L’objectif est de mieux structurer les traitements concurrents afin de :
Même si les changements de cette version restent limités, cette fonctionnalité s’impose progressivement comme un futur pilier du modèle concurrent moderne de Java.
JEP 526 : lazy constants
🟡 En évolution active
Cette JEP introduit des constantes à initialisation différée (lazy constants).
L’idée est de permettre l’initialisation d’une constante uniquement lorsqu’elle devient nécessaire, afin d’optimiser les temps de démarrage et l’utilisation mémoire.
Cette nouvelle itération apporte plusieurs évolutions importantes :
JEP 529 : vector API
🔴 Bloquée
La Vector API poursuit son long cycle d’incubation.
Son objectif est de fournir des opérations vectorielles hautes performances exploitant les capacités modernes des processeurs.
Toutefois, cette évolution reste fortement dépendante du projet Valhalla, dont certaines fonctionnalités sont nécessaires avant une stabilisation complète.
JEP 530 : primitive types in patterns, instanceof, and switch
🟢Stable
Java 26 poursuit l’évolution du pattern matching avec la prise en charge des types primitifs dans :
Cette version ajoute également des vérifications plus strictes pour éviter les conversions avec perte de données.
Exemple : un pattern int appliqué à une valeur long ne sera valide que si la valeur peut réellement être convertie sans perte.
Java 26 offre des évolutions intéressantes, notamment en termes de rigueur du langage (avec la JEP 500 qui renforce la sémantique de final), de nettoyage de l’API (avec la suppression définitive de l’API Applet), d’amélioration des performances (avec les JEP 516 et 522) et de modernisation (avec le support du protocole HTTP/3).
Côté previews, nous retiendrons surtout l’approche de la finalisation pour la Structured Concurrency et les Primitive Types in Patterns, tandis que les Lazy Constants continuent d’évoluer activement.
Ces évolutions s’inscrivent, comme souvent dans les versions entre des LTS, dans une optique de solidification du langage et de préparation des futures évolutions majeures (comme le Projet Valhalla).
À LIRE AUSSI :
À LIRE AUSSI :
