Java SE 27 et OpenJDK 27 publiés

Après six mois de développement, Oracle a publié Java SE 27 (Java Platform, Standard Edition 27), qui utilise le projet open source OpenJDK comme implémentation de référence. À l'exception de la suppression de certaines fonctionnalités obsolètes, Java SE 27 conserve la compatibilité ascendante avec les versions précédentes de la plateforme Java : la plupart des projets Java écrits antérieurement fonctionneront sans modification avec la nouvelle version. Des versions prêtes à installer de Java SE 27 (JDK, JRE et Server JRE) sont disponibles. Linux (x86_64, AArch64), Windows (x86_64) et macOS (x86_64, AArch64). Développée par le projet OpenJDK, l'implémentation de référence Java SE 27 est entièrement open source sous la licence GPLv2 avec l'exception GNU ClassPath, qui permet la liaison dynamique avec des produits commerciaux.

Java SE 27 est une version à support régulier, avec des mises à jour publiées jusqu'à la prochaine version. La branche à support à long terme (LTS) est Java SE 25, Java SE 21 ou Java SE 17, avec des mises à jour publiées respectivement jusqu'en 2033, 2031 et 2029 (généralement disponibles jusqu'en septembre 2030, 2028 et 2026). Le support étendu pour la branche LTS de Java SE 8 se poursuivra jusqu'en 2030, et pour Java SE 11, jusqu'en 2032.

Les modifications apportées à Java SE 27 (1, 2, 3, 4) incluent :

• Par défaut, tous les environnements utilisent le ramasse-miettes G1 (Garbage-First), précédemment utilisé pour les systèmes serveurs. G1 est optimisé pour les systèmes multiprocesseurs à grande capacité de mémoire et pour un équilibre entre latence prévisible et débit élevé. Lors de son fonctionnement, G1 divise la mémoire en de nombreuses petites régions et privilégie celles contenant le plus d'objets inutilisés et les données les moins fréquemment consultées.
• La JVM HotSpot utilise par défaut des en-têtes d'objets compacts. Sur les systèmes 64 bits, la taille de ces en-têtes a été réduite de 96 à 64 bits, ce qui diminue la consommation de mémoire et augmente la probabilité que les données soient mises en cache par le processeur. Lors des tests de performance SPECjbb2015, la consommation de mémoire a diminué de 22 %, la charge du processeur de 8 % et le nombre d'opérations de ramasse-miettes de 15 %. Les temps d'exécution des tests de l'analyseur JSON ont été réduits de 10 %.
• L'implémentation TLS 1.3 ajoute la prise en charge des schémas d'échange de clés hybrides qui combinent l'algorithme ML-KEM (CRYSTALS-Kyber), résistant aux attaques quantiques, avec les algorithmes classiques de courbes elliptiques ECDHE : X25519MLKEM768 (ECDHE avec la courbe X25519 + ML-KEM-768), SecP256r1MLKEM76 (ECDHE avec la courbe secp256r1 + ML-KEM-768) et SecP384r1MLKEM1024 (ECDHE avec la courbe secp384r1 + ML-KEM-1024). Cette prise en charge est disponible dans l'API javax.net.ssl Ces schémas sont activés par défaut et ne nécessitent aucune modification de l'application pour être utilisés.
• JDK Flight Recorder (JFR), un outil de surveillance des performances, de profilage et de diagnostic, prend désormais en charge la suppression des arguments de ligne de commande, des valeurs initiales des variables d'environnement et des propriétés système dans les informations de diagnostic enregistrées. Cette modification empêche la fuite de données sensibles traitées par le processus profilé, telles que les jetons d'autorisation et les clés d'accès API transmises via les variables d'environnement.
• La troisième préversion de l'API Lazy Constants a été implémentée pour la manipulation d'objets contenant des données immuables et traités comme des constantes dans la JVM. Des optimisations de performances similaires à celles appliquées aux champs avec le mot-clé « final » sont utilisées pour ces objets. Contrairement à « final », la nouvelle API dissocie la création des valeurs constantes de leur initialisation, garantit qu'une valeur ne peut être initialisée qu'une seule fois, réduit le temps de démarrage du programme et permet d'utiliser les optimisations de repliement des constantes, auparavant réservées au code interne du JDK, dans le code utilisateur. class Application { // Auparavant : // static final UserService USERS = new UserService(); // Maintenant : static final StableValue UTILISATEURS = StableValue.of(); public static UserService utilisateurs() { return UTILISATEURS.orElseSet(UserService::new); } }
• Le moteur de correspondance de motifs introduit une cinquième version permettant d'utiliser des types primitifs (int, byte, char et autres types de base non-objets) dans tous types de motifs, dans l'opérateur instanceof et dans les blocs switch. switch (x.getStatus()) { case 0 -> "okay"; case 1 -> "warning"; case 2 -> "error"; case int i -> "unknown status: " + i; } if (i instanceof byte b) { … b … }
• La septième version préliminaire de l'API de concurrence structurée, qui simplifie le développement d'applications multithread en traitant plusieurs tâches exécutées sur différents threads comme une seule unité, a été publiée pour test.
• La douzième implémentation de test de l'API Vector a été réalisée. Cette API fournit des fonctions pour les calculs vectoriels effectués à l'aide des instructions vectorielles des processeurs x86_64 et AArch64 et permet les opérations simultanées sur plusieurs valeurs (SIMD). Contrairement à la vectorisation automatique des opérations scalaires par le compilateur JIT HotSpot, la nouvelle API permet un contrôle explicite de la vectorisation pour le traitement parallèle des données.
• Une troisième version de l'API est désormais disponible pour l'encodage et le décodage d'objets contenant des clés cryptographiques, des certificats et des listes de révocation de certificats utilisant le format PEM (Pivacy-Enhanced Mail).

De plus, nous sommes heureux d'annoncer la publication d'une mise à jour de la plateforme JavaFX 27 pour la création d'applications d'interface utilisateur graphique. La publication de la machine virtuelle universelle GraalVM 27, qui prend en charge l'exécution d'applications en JavaScript (Node.js), Python, Ruby, R, tout langage JVM (Java, Scala, Clojure, Kotlin) et les langages pour lesquels du bitcode LLVM peut être généré (C, C++, Rust), est également prévue dans les prochaines heures.

Source: opennet.ru