Nouveautés Java 26 : API allégées, performances renforcées et modernisation avec HTTP/3

Les nouveautés les plus marquantes ? Une API de réflexion renforcée, la disparition définitive de l'API Applet, des performances améliorées, et l'arrivée du support HTTP/3.

Explorez notre analyse.

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 :

class C {
    final String finalField;
    C() { finalField = "Bonjour"; }
}

java.lang.reflect.Field f = C.class.getDeclaredField("finalField");
f.setAccessible(true);

C obj = new C();
System.out.println(obj.finalField);  // Prints "Bonjour"

f.set(obj, "Au revoir");
System.out.println(obj.finalField);  // Prints "Au revoir"

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.

WARNING: Final field x in class [...].C has been mutated reflectively by class [...].FinalMain in unnamed module @7adf9f5f
WARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled

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 sont :

• java.applet.Applet
• java.applet.AppletContext
• java.applet.AppletStub
• java.applet.AudioClip
• java.beans.AppletInitializer
• javax.swing.JApplet

JEP 516 : Ahead-Of-Time object caching with any GC

Java 26 propose une amélioration du cache AOT (Ahead-of-Time) pour les 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.

var client = HttpClient.newBuilder()
       .version(HttpClient.Version.HTTP_3)
        .build();

var request = HttpRequest.newBuilder(URI.create("https://www.sqli.com/"))
        .version(HttpClient.Version.HTTP_3)
        .GET().build();

JEP 522 : G1 GC - improve throughput by reducing synchronization

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é.

Java 26 : les fonctionnalités en preview ou en incubation

Java 26 intègre également des fonctionnalités qui ne sont pas encore finalisées, et donc susceptibles d’évoluer, afin d’obtenir des retours concrets de la communauté. 

Elles peuvent généralement être classées en trois niveaux de maturité :

• 🟢 Stable : Peu ou pas de changements, la fonctionnalité est presque finalisée
• 🟡 En évolution active : Des changements significatifs sont encore en cours
• 🔴 Bloquée : La fonctionnalité est en attente d’un prérequis externe

Pour rappel : afin de les activer, le programme doit être compilé avec des options spécifiques (par exemple, --enable-preview).

Passons-les en revue.

JEP 524 : PEM encodings of cryptographic objects

🟡 En évolution active 

Java 26 propose cette JEP en preview pour la deuxième fois, après une première preview en Java 25.

Le but initial est de proposer une API concise pour gérer les clés cryptographiques et les certificats au format PEM (Privacy-enhanced Electronic Mail), un format de fichier largement utilisé.

Les retours de la précédente preview ont été pris en compte et ont permis de :

• Ajouter la prise en charge de nouveaux types d’objets cryptographiques (par exemple, les certificats X.509)
• Améliorer la gestion des exceptions et le nommage des classes et méthodes
• Ajouter de nouvelles interfaces

JEP 525 : structured concurrency

🟢Stable

La gestion de la concurrence est un problème récurrent en programmation, et Java propose depuis longtemps des outils pour y faire face (threads, executors, etc). Cette JEP est proposée en preview depuis Java 21 après avoir commencé à être incubée en Java 19.

Elle est à nouveau proposée en preview dans Java 26 (sixième fois). Le nombre d’itérations ici est inhabituel pour une JEP, mais expliqué par la complexité particulièrement élevée du sujet.

L’objectif est de proposer des API pour structurer la concurrence, réduire les risques naturels de cette pratique de développement, et permettre une meilleure observabilité. Dans cette version, peu de changements : quelques nouvelles fonctions et évolutions de l'interface Joiner.

JEP 526 : lazy constants

🟡 En évolution active 

Java 26 propose cette JEP en preview pour la deuxième fois, après une première preview en Java 25.

L’objectif est de proposer les lazy constants, c’est-à-dire des constantes (comme un champ qui serait déclaré final) mais qui offrent plus de flexibilité quant au moment où elles sont initialisées. Cela permet d’initialiser une constante à la demande, plutôt qu’au démarrage, et donc d’améliorer les performances.

Cette deuxième itération propose beaucoup de changements :

• Réorientation de l’API pour proposer une interface de plus haut niveau, dont l’intention est plus claire
• Renommage de l’API de StableValue à LazyConstant, pour mieux refléter son intention
• Déplacement de certaines API dans les classes appropriées pour une meilleure organisation du code (les méthodes concernant des Map dans la classe java.util.Map par exemple)

JEP 529 : vector API

🔴 Bloquée

Cette JEP est proposée en incubation depuis Java 16, pour la 11ème fois.

Elle a pour enjeu de proposer une API pour les opérations vectorielles, et améliorer leurs performances sur tous types de CPU.

Aucun changement significatif n’a été apporté à l’API depuis la dernière itération. La fonctionnalité restera en incubation jusqu’à ce que le Projet Valhalla passe officiellement en preview afin de pouvoir utiliser les fonctionnalités de ce dernier dans l’API Vector.

JEP 530 : primitive types in patterns, instanceof, and switch

🟢Stable

Java 26 propose cette JEP en preview pour la quatrième fois, après une première preview en Java 23.

Cette JEP propose l’utilisation de types primitifs dans les patterns, les expressions instanceof et les instructions switch.

La fonctionnalité n’a pas évolué dans ses deux dernières itérations, mais celle-ci propose deux changements :

• Les correspondances avec des types primitifs vérifient maintenant que la conversion se fait sans perte de données. Par exemple, un pattern int appliqué à une valeur long ne sera valide que si la valeur tient effectivement dans un int
• Vérifications plus poussées dans le pattern matching des instructions switch pour détecter certaines erreurs de programmation à la compilation

Conclusion

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).

Pour en savoir plus

OpenJDK – JDK 26

OpenJDK – Projet Valhalla