Sortie officielle de Java 25 / JDK 25

• Java 25 et son implémentation de référence JDK 25 ont été officiellement publiés
• Cette version inclut 18 nouveaux JEP (Java Enhancement Proposal)
• Parmi les principaux changements : suppression du port x86 32 bits, Scoped Values, Structured Concurrency, améliorations des Primitive Types

---

Java 25 / JDK 25 : sortie officielle

• JDK 25, c’est-à-dire l’implémentation de référence de Java 25, a été officiellement publié en version prête pour la production
• Le 15 août 2025, le deuxième release candidate, build 36, a été mis à disposition ; depuis, aucun bug critique (P1) n’a été signalé.
• Le build 36 constitue la version GA (General Availability) finale et peut être utilisé en environnement de production

• Le build OpenJDK sous licence GPL est fourni officiellement par Oracle, et des builds d’autres éditeurs devraient également être diffusés prochainement

Lien officiel de téléchargement OpenJDK

Fonctionnalités et améliorations principales

Cette release inclut 18 JEP (Java Enhancement Proposal)

• 470 : encodage d’objets cryptographiques basé sur PEM (preview)
• 502 : Stable Values (preview)
• 503 : suppression du port x86 32 bits
• 505 : Structured Concurrency (5e preview)
• 506 : Scoped Values
• 507 : prise en charge des Primitive Types dans les patterns, instanceof et switch (3e preview)
• 508 : Vector API (10e version incubateur)
• 509 : profilage du temps CPU avec JFR (fonction expérimentale)
• 510 : Key Derivation Function API
• 511 : déclarations Module Import
• 512 : Compact Source Files et méthode main d’instance
• 513 : Flexible Constructor Bodies
• 514 : optimisation Ahead-of-Time en ligne de commande
• 515 : profilage de méthodes Ahead-of-Time
• 518 : échantillonnage coopératif JFR
• 519 : Compact Object Headers
• 520 : timing et traçage de méthodes JFR
• 521 : Generational Shenandoah

En plus des JEP ci-dessus, cette release intègre également des centaines de petites améliorations fonctionnelles et des milliers de corrections de bugs

Pour plus d’informations sur cette release et le détail des JEP, voir la
page du projet OpenJDK JDK 25

[ahwjdekf]

Le revoilà, comme l’an dernier, il n’est ni mort ni enterré, allez hop, ça repart... Pourquoi est-ce que tu reviens sans arrêt ?

[click]

C’est une fonctionnalité arrivée avec JDK 24, mais comme Java a tendance à être utilisé surtout en version LTS, il est aussi intéressant de noter qu’avec le JEP 491: Synchronize Virtual Threads without Pinning, le phénomène de pinning des threads virtuels lors de l’utilisation du mot-clé synchronized a disparu.
Il arrivait assez souvent que les benchmarks en conditions réelles des threads virtuels soient plus lents, et dans la plupart des cas, le pinning en était la cause.

[GN⁺]

Avis Hacker News

• Je pense que davantage de nouveaux programmes devraient être écrits en Java ou sur la JVM ; la plupart des raisons du déclin de popularité de Java ont désormais pratiquement disparu, et c’est aujourd’hui un écosystème très stable et mature. Même un programme Clojure que j’ai écrit il y a 10 ans tourne toujours sans problème, alors qu’un programme écrit en TypeScript a besoin de maintenance et de mises à jour au bout de 6 mois.
  • Oracle reste un gros point d’inquiétude ; c’est pénible de devoir faire attention à ne pas violer l’EULA d’Oracle en utilisant Java. Avec openjdk, ça semble aller, mais je préférerais quand même utiliser un autre langage pour ne pas avoir à m’en soucier. C# offre lui aussi un environnement comparable à Java sans les inquiétudes liées à Oracle. Plutôt que d’apprendre à utiliser Java « en toute sécurité », je pense qu’il vaut mieux simplement choisir un autre langage. Java n’est pas indispensable, donc les alternatives ne manquent pas.
  • Java reste extrêmement populaire et largement utilisé dans les gros systèmes backend. Je suis surpris qu’il semble y avoir si peu de gens ici qui travaillent sur ce genre de systèmes ; dans mon expérience, Java est presque incontournable.
  • J’espère discrètement que Kotlin et Compose redonneront vie aux applications desktop sur la JVM.
  • Je pense que le risque persistant de Java en matière d’adoption, c’est sa culture associée. Les anciens développeurs Java et les programmes Java existants sont souvent écrits de manière inutilement verbeuse, alors que le langage lui-même dispose déjà de fonctionnalités permettant d’écrire de façon concise comme les autres langages modernes. Cela dit, Java a un poids tel que je pense qu’il peut encore évoluer.
  • Je me demande si le fait qu’un programme Clojure écrit il y a 10 ans tourne encore bien vient de la JVM ou de l’approche propre à Clojure. J’ai eu une expérience similaire avec un projet ClojureScript ; même de vieux scripts nbb fonctionnent immédiatement sans gros souci (à part parfois ajuster un peu les dépendances npm). À l’inverse, avec Python, il m’est arrivé de perdre une demi-journée à cause de problèmes de dépendances et de gestion de venv.
• Java a longtemps constitué une base technique étonnamment solide. Ce n’est pas le langage le plus séduisant, mais il fait toujours preuve de stabilité. Une application conçue avec Java 1.4 fonctionne encore très bien sur Java 21 LTS, et nous prévoyons bientôt de passer à Java 25. Java au top.
  • Je me demande où en serait Java aujourd’hui sans les excellents outils de JetBrains et son programme étudiant particulièrement malin.
  • À bonne distance, mais je me souviens encore de l’application Gmail en Java qui tournait sur mon téléphone Symbian tactile en 2009. Elle était vraiment mignonne et très fonctionnelle.
  • D’après mon expérience, je ne peux pas être totalement d’accord. Dans plusieurs entreprises, chaque montée de version de la JVM a toujours entraîné de gros problèmes, beaucoup de réécriture et de revalidation. J’ai arrêté vers Java 17~18, mais les gens avec qui je travaillais n’utilisaient presque jamais les nouvelles versions. En 2022, sur un projet, il a fallu mettre à jour une JVM 1.5, et ça a été très compliqué parce que des bibliothèques tierces critiques ne supportaient que les versions antérieures à Java 1.7. On a essayé de récupérer le code source pour les recompiler nous-mêmes, mais l’ampleur du travail n’a cessé de grandir. Ça s’est mal passé avec le management, et j’ai fini par décider de quitter le client principal d’une Fortune 10. D’après ce que j’ai entendu, ce système n’a toujours pas été mis à jour.
  • J’aimerais réessayer une ancienne application Swing que j’avais écrite ; j’ai l’impression qu’il serait possible de la ressusciter sans grosses modifications, donc je pense tenter le coup.
  • La JVM et son écosystème peuvent aussi être utilisés avec d’autres langages comme Scala ou Clojure, ce qui permet des usages variés et intéressants.
• Je trouve étonnant qu’il ait fallu autant de temps avant d’autoriser la validation et la transformation des paramètres avant l’appel à super dans le constructeur ; ça m’a toujours semblé contre-intuitif.
  • J’utilise Java depuis avant JDK 1.0, et ce point m’agaçait déjà à l’époque, mais je m’y suis désormais habitué et je connais bien les contournements.
  • Si on utilisait une fonction static pour la validation dans les paramètres passés à super, elle était en pratique appelée avant super, donc le compilateur n’y voyait aucun problème.
• Je ne suis pas développeur Java, mais personnellement je n’aime pas beaucoup son système d’import de modules. Une syntaxe comme import * est facile à écrire, mais bien plus difficile à lire, surtout pour les développeurs qui ne connaissent pas bien le langage ou la base de code. C# et Nim ont aussi ce style, et sans IDE je trouve ça presque illisible. C’est pourquoi je préfère des alias courts comme en Python (import torch.nn.functional as F).
  • Dans une grosse base de code, le principal problème des imports, c’est : « ça vient d’où ? ». Les imports explicites sont indispensables, surtout quand le build casse ou qu’il y a une confusion sur les versions de dépendances. Dans une petite base de code, peu importe ; de toute façon, les éditeurs modernes masquent souvent les imports, donc on les regarde rarement directement, on clique sur le code ou on suit un raccourci, donc je n’y prête pas beaucoup attention.
  • Je pense que si ton expérience avec C# n’a pas été bonne, c’est surtout parce que tu n’utilisais pas un vrai Visual Studio. VSCode est bien, mais je n’ouvrirais jamais un fichier csproj ou sln avec VSCode. À titre indicatif, Visual Studio peut être acheté ici pour 500 $ avec une licence perpétuelle, sans abonnement séparé.
  • Je ne comprends pas qu’on se plaigne de constructions de langage difficiles à comprendre sans IDE ; on regarde le code dans un IDE, donc ça ne me semble pas être un problème. Ceux qui n’utilisent pas d’IDE se créent eux-mêmes cette difficulté, et regarder du code sur GitHub ne consiste généralement pas à analyser très en profondeur les références, donc ce niveau d’inconfort en échange de concision reste acceptable.
  • Si je comprends bien, ce style a été pensé pour faciliter l’écriture de programmes à fichier source unique.
• Les nouvelles fonctionnalités sont bien récapitulées sur la page officielle OpenJDK 25, et Java 25 est une version LTS.
  • J’espère que le jour où il faudra migrer de 17 vers 25 dans 10 ans arrivera vite.
• Impression personnelle : bien que Java soit un vieux langage, il a continué à progresser régulièrement ces 10 dernières années, alors que C++ me semble au contraire être devenu plus difficile.
• Malheureusement, structured concurrency n’est pas encore totalement publiée. J’attends vraiment cette fonctionnalité avec impatience. En revanche, l’ajout de Scoped Values est une bonne nouvelle ; à lui seul, je pense que cela permet de structurer le code dans un style « rails-like » en Java sans abuser des god-class ou god-object.
  • Par rapport à la situation confuse de C++, avec des fonctionnalités standardisées sans implémentation réelle, je trouve que l’approche progressive de Java via les previews est bien meilleure.
  • J’espère que structured concurrency donnera l’impression d’un vrai progrès, et pas d’un mécanisme trop « sucré » à la async/await. À voir les exemples, je ne suis pas encore convaincu, mais je vais continuer à suivre ça.
• J’ai récemment décidé de migrer depuis JDK8 et je suis passé directement à JDK21. Comme la 25 est toute proche, j’ai choisi 21 plutôt que de m’arrêter à 17. De mon point de vue, la migration la plus difficile a été de 8 vers 11 (avec l’arrivée du nouveau système de modules) ; après ça, c’est devenu plus simple. Le proof-of-concept a été fait en jdk17, et il fonctionnait quasiment tel quel en jdk21 (seul guice a nécessité une montée de version majeure). À noter que le fait d’utiliser un autre langage JVM à la place de Java a sans doute aussi aidé.
  • Pour notre équipe, le passage de 8 à 17 a été difficile. Nous utilisions beaucoup de choses non officielles comme les packages sun, et le passage de javax à jakarta a aussi été lourd. Une fois cette étape franchie, aller vers 21 ou 25 semble facile. J’espère qu’à l’avenir, suivre régulièrement les dernières versions sera plus simple qu’avant.
  • Java 9 a été le moment « Python 3 » de l’écosystème, mais j’ai l’impression que tout est désormais rentré dans l’ordre.
  • Pour info, j’ai récemment migré de 17 vers 21 sans rencontrer le moindre problème. Il y a juste eu quelques petits soucis lors de la montée de version de Gradle en même temps (mais c’est fondamentalement un autre sujet).
• Les nouveautés de Java 25 sont aussi bien résumées dans ce post baeldung.
• Je me demande quelle est aujourd’hui la situation juridique autour de l’utilisation de Java, en open source comme en usage commercial. Oracle garde de très bonnes technologies comme Truffle liées à Java, et je voudrais savoir à quel point il est raisonnable de l’utiliser dans de nouveaux projets.
  • OpenJDK est en pratique la version open source directement issue d’Oracle. Si Oracle ne te plaît pas, tu peux utiliser les distributions d’autres acteurs comme l’Eclipse Foundation, Microsoft ou Amazon. Java a une très longue durée de vie, ce qui explique aussi pourquoi on utilise encore d’anciennes versions comme 8 ou 11 : une fois écrit, ça tourne vraiment très longtemps. Côté fonctionnalités, il avance plus lentement que ses concurrents, mais pour du développement important il est largement suffisant. Si tu dépends de la JVM, je recommande Kotlin (surtout que Java n’a toujours pas de nullable type, donc les NullPointerException restent fréquentes). Si Kotlin ne te convient pas, C# est aussi un bon choix. Malgré tout, Java reste tout à fait utilisable.
  • À l’heure actuelle, pour la distribution Oracle, on peut considérer que seule la dernière LTS est librement utilisable. Les versions inférieures relèvent de la licence OTN, donc seulement pour un usage personnel ou de développement, pas en production. Si tu n’as pas absolument besoin de la marque Oracle, OpenJDK ou les JDK d’autres fournisseurs ne posent aucun souci de licence.
  • OpenJDK est totalement open source, donc il n’y a vraiment aucune inquiétude à avoir.
  • Si tu utilises quelque chose comme OpenJDK, tu es complètement à l’abri des problèmes liés à Oracle.
  • À moins de créer et distribuer toi-même une implémentation Java, les questions juridiques ne sont pratiquement pas un sujet.