{"id":1946,"date":"2025-07-04T10:47:15","date_gmt":"2025-07-04T08:47:15","guid":{"rendered":"https:\/\/www.loicmathieu.fr\/wordpress\/?p=1946"},"modified":"2026-01-21T17:56:32","modified_gmt":"2026-01-21T16:56:32","slug":"java-25-whats-new","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/informatique\/java-25-quoi-de-neuf\/","title":{"rendered":"Java 25 : Quoi de neuf?"},"content":{"rendered":"

Maintenant que Java 25 est features complete (Rampdown Phase One au jour d\u2019\u00e9criture de l\u2019article), c\u2019est le moment de faire le tour des fonctionnalit\u00e9s qu\u2019apporte cette nouvelle version, \u00e0 nous, les d\u00e9veloppeurs.<\/p>\n

Cet article fait partie d\u2019une suite d\u2019article sur les nouveaut\u00e9s des derni\u00e8res versions de Java<\/a>, pour ceux qui voudraient les lire en voici les liens : Java 24<\/a>, Java 23<\/a>, Java 22<\/a>, Java 21<\/a>, Java 20<\/a>, Java 19<\/a>, Java 18<\/a>, Java 17<\/a>, Java 16<\/a>, Java 15<\/a>, Java 14<\/a>, Java 13<\/a>, Java 12<\/a>, Java 11<\/a>,\u00a0Java 10,<\/a>\u00a0et\u00a0Java 9<\/a>.<\/p>\n

Java 25 est la nouvelle version \u00e0 support \u00e0 long terme (LTS), elle contient pas moins de 18 JEPs. M\u00eame si c’est moins bien que les 24 JEPs de Java 24 c’est quand m\u00eame un chiffre assez important.\nPas de grosses nouveaut\u00e9s au programme, mais plusieurs petites nouveaut\u00e9s sympas tout de m\u00eame.<\/p>\n

JEP 470: PEM Encodings of Cryptographic Objects (Preview)<\/h2>\n

Nouvelle fonctionnalit\u00e9 en preview qui apporte le support du format Privacy-Enhanced Mail<\/a> (PEM) \u00e0 Java.<\/p>\n

Ce format est tr\u00e8s r\u00e9pandu pour communiquer, par exemple, des cl\u00e9s ou des certificats, car c’est un format textuel simple \u00e0 utiliser. C’est aussi un standard de PKCS#8<\/a>.<\/p>\n

Ce format est maintenant support\u00e9 pour les cl\u00e9s priv\u00e9es, les cl\u00e9s publiques, les certificats et les listes de r\u00e9vocations de certificats.<\/p>\n

Un texte PEM est une repr\u00e9sentation encod\u00e9e en Base64 d’un objet cryptographique.\nPar exemple, pour une cl\u00e9 publique de type elliptic curve :<\/p>\n

\n-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi\/kRGOL7wCPTN4KJ2ppeSt5UYB6u\ncPjjuKDtFTXbguOIFDdZ65O\/8HTUqS\/sVzRF+dg7H3\/tkQ\/36KdtuADbwQ==\n-----END PUBLIC KEY----- \n<\/pre>\n
Pour encoder un objet cryptographique au format PEM on va utiliser la nouvelle classe PEMEncoder<\/code> :<\/p>\n
\nPEMencoder pe = PEMEncoder.of();\n\n\/\/ plaintext\nbyte[] pem = pe.encode(publicKey);\n\n\/\/ password encrypted\nbyte[] pemWithPassword = pe.withEncryption(password).encode(privateKey);\n<\/pre>\n
On peut fournir un mot de passe pour encoder le texte PEM avec la m\u00e9thode withEncryption()<\/code> ; on peut aussi directement encoder en String via la m\u00e9thode encodeToString()<\/code>.<\/p>\n
Pour d\u00e9coder un texte PEM en un objet cryptographique, on va utiliser la nouvelle classe PEMDecoder<\/code> :<\/p>\n
\nPEMDecoder pd = PEMDecoder.of();\n\n\/\/ plaintext\nCertificate cert = pd.decode(pem, X509Certificate.class);\n\n\/\/ password encrypted\nCertificate certWithPassord = pd.withDecryption(password)\n    .decode(pem, X509Certificate.class);\n<\/pre>\n
Plus d’information dans la JEP 470<\/a>.<\/p>\n
JEP 502: Stable Values (Preview)<\/h2>\n
Nouvelle fonctionnalit\u00e9 en preview qui permet de cr\u00e9er des variables stables<\/em> qui vont se comporter comme des variables finales mais avec une plus grande flexibilit\u00e9 pour leur initialisation.<\/p>\n
Une stable value ne peut \u00eatre initialis\u00e9e qu’une seule fois et est immuable.<\/p>\n
Il est assez classique de retarder l’initialisation d’un attribut d’une classe lors de sa premi\u00e8re utilisation pour \u00e9viter de ralentir le d\u00e9marrage de l’application, ou m\u00eame \u00e9viter d’initialiser un attribut non utilis\u00e9 !\nPour faire \u00e7a de mani\u00e8re coh\u00e9rente et s\u00fbre dans des sc\u00e9narios multi-thread, il faut utiliser une construction assez compliqu\u00e9e \u00e0 base de double-checked locking<\/a> ou de class-holder idiom<\/a>.<\/p>\n
Avec les Stable Values, nous avons maintenant une API pour \u00e7a !<\/p>\n
\nprivate final StableValue logger = StableValue.of();\n\nLogger getLogger() {\n    return logger.orElseSet(() -> Logger.create(MyClass.class));\n}\n\nvoid saySomething() {\n    getLogger().info(\"I have nothing to say\");\n}\n<\/pre>\n
Il y a plusieurs mani\u00e8res de cr\u00e9er des stable values, au lieu d’utiliser orElseSet()<\/code> on peut utiliser un supplier, exemple :<\/p>\n
\nprivate final Supplier logger = StableValue\n    .supplier(() -> Logger.create(MyClass.class));\n\nvoid saySomething() {\n    logger.get().info(\"I have nothing to say\");\n}\n<\/pre>\n
La JVM va garantir que la stable value logger<\/code> va \u00eatre initialis\u00e9 une et une seule fois, lors de sa premi\u00e8re utilisation, et va permettre au JIT d’en optimiser l’utilisation (constant folding).<\/p>\n
Il est aussi possible de construire une liste de stable values, dont chaque \u00e9l\u00e9ment va \u00eatre initialis\u00e9 une seule fois lors de son premier acc\u00e8s. Tr\u00e8s pratique pour cr\u00e9er des pools d’objets.<\/p>\n
\nstatic final List connections = StableValue\n    .list(POOL_SIZE, _ -> new Connection());\n\nvoid doSomething() {\n    long index = Thread.currentThread().threadId() % POOL_SIZE;\n    Connection con = connections.get((int) index);\n}\n<\/pre>\n
Plus d’information dans la JEP 502<\/a>.<\/p>\n
JEP 503: Remove the 32-bit x86 Port<\/h2>\n
Le port 32-bit pour les architectures x86 de la JVM a \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9 en Java 24 avec l’intention de le supprimer dans une release future, c’est d\u00e9sormais chose faite.<\/p>\n
Le co\u00fbt de maintenance et de d\u00e9veloppement de nouvelles fonctionnalit\u00e9s induit par ce port ne valait pas la peine, car cette architecture n’est quasiment plus utilis\u00e9e. Cela n’impacte pas les autres architecture 32-bit tels que ARM32.<\/p>\n
Pour les architectures non support\u00e9es, il existe un port de la JVM sans sp\u00e9cificit\u00e9 d’architecture : le port Zero, qui permettra toujours de faire tourner une JVM sous architecture 32-bit x86.<\/p>\n
Plus d’information dans la JEP 503<\/a>.<\/p>\n
509: JFR CPU-Time Profiling (Experimental)<\/h2>\n
Fonctionnalit\u00e9 exp\u00e9rimentale qui ajoute la capture des informations de profiling du temps CPU sous Linux \u00e0 Java Flight Recorder (JFR).<\/p>\n
JFR est l’outil de monitoring de production de la JVM, il a un overhead faible et permet d\u00e9j\u00e0 de monitorer l’utilisation m\u00e9moire d’une m\u00e9thode et son temps d’ex\u00e9cution (wall-clock time).<\/p>\n
Pour monitorer le temps d’ex\u00e9cution d’une m\u00e9thode, JFR va sampler la stack d\u2019ex\u00e9cution d’un programme \u00e0 intervalles r\u00e9guliers, par exemple toutes les 20ms.<\/p>\n
Le temps d’ex\u00e9cution d’une m\u00e9thode n’est pas forc\u00e9ment le temps CPU, par exemple, une m\u00e9thode faisant des calculs en m\u00e9moire comme un tri de tableau va principalement consommer du CPU donc son temps d’ex\u00e9cution sera quasiment \u00e9quivalent au temps CPU, au contraire, une m\u00e9thode acc\u00e9dant  \u00e0 une ressource r\u00e9seau va principalement attendre des I\/O et va donc avoir un temps CPU tr\u00e8s faible.<\/p>\n
Les syst\u00e8mes Linux supportent la mesure pr\u00e9cise de la consommation des cycles CPU via l’\u00e9mission de signaux \u00e0 intervalles r\u00e9guliers. C’est ce qui est utilis\u00e9 par la plupart des profilers Linux et dans le monde Java, par exemple par async-profiler<\/a>.<\/p>\n
Avec la JEP 509, JFR peut maintenant utiliser le m\u00e9canisme offert par Linux pour \u00e9mettre un nouvel \u00e9v\u00e9nement de monitoring: jdk.CPUTimeSample<\/code>, ce nouvel \u00e9v\u00e9nement n’est pas actif par d\u00e9faut.<\/p>\n
La ligne de commande suivante va activer l\u2019\u00e9v\u00e9nement au lancement de l’application :<\/p>\n
\njava -XX:StartFlightRecording=jdk.CPUTimeSample#enabled=true,filename=profile.jfr ...\n<\/pre>\n
Pour aller plus loin, vous pouvez lire ces articles fort int\u00e9ressants de Johannes Bechberger Java 25\u2019s new CPU-Time Profiler (1)<\/a>  et Java 25\u2019s new CPU-Time Profiler: The Implementation (2)<\/a>.<\/p>\n
Plus d’information dans la JEP 509<\/a>.<\/p>\n
514: Ahead-of-Time Command-Line Ergonomics<\/h2>\n
La JEP 483: Ahead-of-Time Class Loading & Linking<\/a> a introduit en Java 24 la possibilit\u00e9 de cr\u00e9er un cache AOT (Ahead of Time – avant le lancement de l’application) contenant les classes d\u00e9j\u00e0 charg\u00e9es et li\u00e9es d’une application pour am\u00e9liorer son temps de d\u00e9marrage.<\/p>\n
Cela devait se faire en trois \u00e9tapes :<\/p>\n
  1. Lancement de l’application pour enregistrer la liste des classes utilis\u00e9es<\/li>\n\n
  2. Cr\u00e9ation du cache AOT<\/li>\n\n
  3. Lancement de l’application avec le cache AOT<\/li>\n<\/ol>\n
    Avec la JEP 514, ce processus est simplifi\u00e9, il est maintenant faisable en deux \u00e9tapes uniquement, les deux premi\u00e8res \u00e9tapes pouvant \u00eatre faites en une seule via la ligne de commande :<\/p>\n
    \njava -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App ...\n<\/pre>\n
    La liste des classes sera enregistr\u00e9e pendant le fonctionnement de l’application, puis le cache AOT sera cr\u00e9\u00e9 quand l’application sera arr\u00eat\u00e9e.<\/p>\n
    Plus d’information dans la JEP 514<\/a>.<\/p>\n
    515: Ahead-of-Time Method Profiling<\/h2>\n
    Le cache AOT pr\u00e9sent\u00e9 dans la section pr\u00e9c\u00e9dente s’enrichit des informations de profiling des m\u00e9thodes !<\/p>\n
    Au d\u00e9marrage d’une application Java, le Just-In-Time compiler (JIT) va profiler les m\u00e9thodes Java pour savoir lesquelles doivent \u00eatre compil\u00e9es (celles qui sont fr\u00e9quemment utilis\u00e9es) et guider ces optimisations via de nombreuses heuristiques (branches les plus utilis\u00e9es, taille des boucles, …). C’est seulement apr\u00e8s que ces informations de profiling auront \u00e9t\u00e9 collect\u00e9es que le JIT va pouvoir compiler puis optimiser les classes de l’application.<\/p>\n
    La JEP 515 va \u00e9tendre le cache AOT pour y ajouter les informations de profiling des m\u00e9thodes, ce qui permettra au JIT de commencer avec des informations de profiling, et \u00e0 l’application de d\u00e9marrer plus rapidement et d’attendre plus rapidement ses performances de pointe.\nLe JIT collectera toujours des statistiques au runtime.<\/p>\n
    Des tests pr\u00e9liminaires montrent une am\u00e9lioration de performance de 19% d’un programme simple utilisant l’API Stream pour une augmentation de la taille du cache AOT de seulement 2,5%.<\/p>\n
    Plus d’information dans la JEP 515<\/a>.<\/p>\n
    518: JFR Cooperative Sampling<\/h2>\n
    Comme d\u00e9crit dans la section \u00e0 propos de la JEP 509; pour monitorer le temps d’ex\u00e9cution d’une m\u00e9thode, JFR va sampler la stack d\u2019ex\u00e9cution d’un programme \u00e0 intervalles r\u00e9guliers, par exemple toutes les 20ms. Il va donc collecter l’ensemble des stacks de tous les threads d\u00e9marr\u00e9s. Pour cela, il faut que les threads soient dans un \u00e9tat stable, coh\u00e9rent les uns avec les autres.<\/p>\n
    Pour collecter les informations des threads, on peut utiliser le m\u00e9canisme de safepoint : la JVM demande \u00e0 tous les threads de se suspendre, ceux-ci allant jusqu’\u00e0 un point o\u00f9 ils peuvent se suspendre sans mettre en danger l’application : le safepoint. Ce m\u00e9canisme souffre de biais du safepoint : un thread loin d’un safepoint prendra du temps \u00e0 se suspendre alors qu’un autre proche le fera rapidement.<\/p>\n
    Pour \u00e9viter ce biais, JFR scanne les threads de mani\u00e8re asynchrone et les suspend en dehors d’un safepoint. \u00c9tant donn\u00e9 que les m\u00e9tadonn\u00e9es des stacks de threads ne sont pas garanties comme \u00e9tant valides en dehors des safepoints, JFR utilise des heuristiques afin de g\u00e9n\u00e9rer les stacks des threads.<\/p>\n
    Ce m\u00e9canisme a \u00e9t\u00e9 refait pour analyser les stacks de threads uniquement aux safepoints, \u00e9vitant ainsi les erreurs. Pour contrer le biais de safepoint, JFR enregistre le pointeur de programme lors de la suspension, puis le thread continue et reconstitue sa stack \u00e0 son prochain safepoint. Cela permet une collecte de donn\u00e9es plus pr\u00e9cise et moins risqu\u00e9e.<\/p>\n
    Ce m\u00e9canisme est utilis\u00e9 pour les threads ex\u00e9cutant une m\u00e9thode Java, pour les threads ex\u00e9cutant une m\u00e9thode native, l’\u00e9tat du thread est connu et ne change pas pendant la dur\u00e9e de la m\u00e9thode, JFR peut alors parcourir la stack du thread sans attendre un safepoint.<\/p>\n
    Malgr\u00e9 cela, il reste un probl\u00e8me. Parfois, \u00e0 la reconstruction de la stack au safepoint, JFR ne peut pas r\u00e9soudre la stack avec les informations n\u00e9cessaires, utilisant alors par d\u00e9faut les informations du thread au safepoint, cr\u00e9ant a nouveau un biais.<\/p>\n
    Pour aller plus loin, vous pouvez lire cet article fort int\u00e9ressant de Johannes Bechberger Taming the Bias: Unbiased* Safepoint-Based Stack Walking in JFR<\/a>.<\/p>\n
    Plus d’information dans la JEP 518<\/a>.<\/p>\n
    520: JFR Method Timing & Tracing<\/h2>\n
    Ajoute le tracing et le timing des m\u00e9thodes via instrumentation de bytecode<\/a> \u00e0 Java Flight Recorder (JFR).<\/p>\n
    Pour tracer les invocations de m\u00e9thodes (tracing) : enregistre toutes les statistiques d’invocations au lieu du m\u00e9canisme bas\u00e9 sur du sampling.<\/p>\n
    Pour mesurer les temps d\u2019ex\u00e9cution des m\u00e9thodes (timing) : permet la capture du temps d’ex\u00e9cution ainsi que les stack traces de m\u00e9thodes sp\u00e9cifiques sans n\u00e9cessiter de modification de code source.<\/p>\n
    Pour mesurer le temps d\u2019ex\u00e9cution et tracer les invocations de m\u00e9thodes, on utilise g\u00e9n\u00e9ralement lors du d\u00e9veloppement ou du d\u00e9bugging des outils tels que JMH (Java Micronbenchmark Harness<\/a>), des sampling profilers  ou des agents Java. Ceux-ci ne sont pas faits pour un usage en production et ont souvent un overhead non n\u00e9gligeable.<\/p>\n
    Avec la JEP 520, le JDK se dote d’un outil configurable et fait pour la production pour mesurer le temps d\u2019ex\u00e9cution et tracer les invocations de m\u00e9thodes !<\/p>\n
    Deux nouveaux \u00e9v\u00e9nements jdk.MethodTiming<\/code> et jdk.MethodTrace<\/code> ont \u00e9t\u00e9 ajout\u00e9s \u00e0 JFR; ils sont configurables via un filtre qui permet de pr\u00e9ciser quelles m\u00e9thodes doivent \u00eatre monitor\u00e9es.<\/p>\n
    Par exemple, la commande suivante va activer le tracing de la m\u00e9thode java.util.HashMap::resize<\/code> :<\/p>\n
    \njava -XX:StartFlightRecording:jdk.MethodTrace#filter=java.util.HashMap::resize,filename=recording.jfr ...\n<\/pre>\n
    La ligne de commande suivante va activer le timing de tous les blocs d’initialisation statique :<\/p>\n
    \njava -XX:StartFlightRecording:method-timing=::,filename=clinit.jfr ...\n<\/pre>\n
    Plus d’information dans la JEP 520<\/a>.<\/p>\n
    Les fonctionnalit\u00e9s qui sortent de preview<\/h2>\n
    Les fonctionnalit\u00e9s suivantes sortent de preview (ou du module incubator) et passent en standard :<\/p>\n