Java 26 : Oracle enterre les applets et embarque JavaScript et Python dans la JVM

Ménage de printemps chez "Big Red" — Le 17 mars dernier, Oracle a livré Java 26. Au programme : 10 JEPs, un bon coup de balai dans les API historiques, et en parallèle une conférence JavaOne qui a donné le ton pour la suite du langage.

Adieu les applets, bonjour la modernité ?

Commençons par l'enterrement que beaucoup de monde attendait : Java 26 supprime définitivement l'API Applet (JEP 504), cette technologie qui permettait d'exécuter du Java dans un navigateur web et qui avait en quelque sorte fait la célébrité du langage dans les années 2000 (oh les souvenirs 🥲).

Dépréciée depuis Java 9, candidate à la suppression depuis Java 17, elle avait déjà perdu tout support navigateur depuis des lustres. Le comble ? JavaScript, créé à l'origine par Netscape en 1995 pour scripter les applets Java, leur survit allègrement. Et les deux langages n’ont d'ailleurs pas fini de cohabiter.

Dans la foulée, Java 26 s'attaque à un autre héritage encombrant avec la JEP 500 : la possibilité de modifier un champ final par réflexion. Jusqu'ici, un Field.setAccessible(true) suivi d'un Field.set() permettait joyeusement de rendre mutable ce qui était censé ne pas l'être. La JVM émet désormais un warning au runtime, et une future version passera à l'exception pure et simple. Quand final voudra enfin dire final, ça pourrait bien piquer pour certaines bibliothèques de sérialisation.

HTTP/3, ramasse-miettes dopé et démarrage accéléré

Côté nouveautés concrètes, le client HTTP intégré à Java supporte maintenant le protocole HTTP/3, basé sur QUIC (JEP 517). Pour rappel, HTTP/3 remplace TCP par UDP pour réduire la latence des connexions, et c'est déjà le protocole utilisé par une bonne partie du web moderne.

L'activation reste explicite via HttpClient.Version.HTTP_3, avec un repli automatique vers HTTP/2 si le serveur ne gère pas encore HTTP/3. Plusieurs stratégies de négociation sont disponibles, de la plus agressive (HTTP/3 uniquement) à la plus prudente (on tente d'abord, on se rabat ensuite).

Le garbage collector G1 (le ramasse-miettes par défaut depuis Java 9) gagne en performances grâce à la JEP 522. L'idée : dédoubler la structure interne qui traque les références entre objets, pour que le GC puisse faire son ménage en parallèle sans ralentir votre application.

Oracle annonce des gains de débit de 5 à 15% sur les applications qui manipulent beaucoup de références, et jusqu'à 5% de bonus sur x64 même pour les autres.

L'AOT cache (JEP 516), qui permet de mettre en cache des objets Java pré-initialisés pour accélérer les lancements suivants, devient compatible avec tous les garbage collectors (dont ZGC). Et les Lazy Constants (JEP 526, ex-"Stable Values") permettent d'initialiser une valeur au moment où on en a réellement besoin plutôt qu'au démarrage de l'application, ce qui améliore sensiblement le temps de boot.

Côté previews, certaines features prennent leur temps : la Structured Concurrency en est à sa sixième itération, et la Vector API à sa onzième incubation 😬 — celle-ci reste bloquée en attendant que le projet Valhalla (la refonte du système de types de Java, qui doit notamment introduire les "value classes" pour améliorer drastiquement les performances) daigne passer en preview.

Le projet Detroit : V8 et CPython directement dans la JVM

C'est la grosse annonce de l’événement JavaOne qui s’est tenu du 17 au 19 mars à Redwood City (Californie) : le projet Detroit, initialement lancé en 2018 puis abandonné, revient sur la table.

Son principe : embarquer les runtimes V8 (JavaScript) et CPython directement dans le processus JVM, plutôt que de réimplémenter ces langages au-dessus de la machine virtuelle.

La logique est pragmatique : plutôt que de réimplémenter JavaScript ou Python from scratch (comme l'avait tenté le projet Nashorn, retiré du JDK en 2020), Oracle préfère intégrer les runtimes de référence que tout le monde utilise déjà. Moins de maintenance, et une compatibilité garantie avec les écosystèmes existants.

L'approche repose sur l'API FFM (Foreign Function and Memory) introduite en Java 22, qui remplace l'ancien JNI (Java Native Interface, le mécanisme historique pour appeler du code natif C/C++ depuis Java) pour l'interopérabilité native.

Oracle promet de meilleures performances et un modèle de sécurité plus propre, avec une isolation nette entre le heap Java et ceux de V8 ou CPython. Le projet sera proposé à l'OpenJDK prochainement, avec JavaScript et Python en premiers langages supportés, et d'autres à suivre.

JavaFX revient, Helidon s'aligne

Parmi les autres annonces de JavaOne, Oracle ressuscite le support commercial de JavaFX pour répondre à la demande croissante en visualisations interactives — portées par la vague IA et les besoins en data science.

Le framework rejoint le nouveau Java Verified Portfolio (JVP), un ensemble sélectionné de composants certifiés Oracle qui inclut aussi Helidon, le framework microservices cloud native, et l'extension Java pour VS Code.

Helidon voit justement son calendrier de releases aligné sur celui du JDK, ce qui devrait garantir un support immédiat des nouvelles versions de Java dès leur sortie.

Pour les devs Java qui font de l'IA, Helidon AI et l'intégration LangChain4j sont mis en avant. On notera aussi que JavaDoc dispose maintenant d'un dark mode. Ce n'est pas une JEP, mais franchement, c’est appréciable.

En attendant Valhalla

Java 26 reste une release de transition (supportée seulement 6 mois, pour rappel la prochaine LTS sera Java 29 en septembre 2027), mais le signal est clair : plusieurs JEPs, notamment les restrictions sur final et le gel de la Vector API, ressemblent fort à des travaux préparatoires pour les premières features du projet Valhalla.

Quand les value classes débarqueront, elles devraient sensiblement améliorer les performances des objets légers et immuables, un changement attendu de longue date par l'écosystème. En attendant, Oracle consolide les fondations, enterre ce qui devait l'être, et parie sur l'interopérabilité “multilingue" avec le projet Detroit.