Sortie de Java SE 24 et OpenJDK 24

Après six mois de développement, Oracle a publié la plateforme Java SE 24 (Java Platform, Standard Edition 24), dont la référence est le projet open source OpenJDK. À l'exception de la suppression de certaines fonctionnalités obsolètes, Java SE 24 conserve la compatibilité descendante avec les versions précédentes de la plateforme Java : la plupart des projets Java antérieurs fonctionneront sans modification sous cette nouvelle version. Les versions prêtes à installer de Java SE 24 (JDK, JRE et Server JRE) sont disponibles pour Linux (x86_64, AArch64), Windows (x86_64) et macOS (x86_64, AArch64). La référence de Java SE 24, développée dans le cadre du projet OpenJDK, est entièrement ouverte sous licence GPLv2, avec des exceptions GNU ClassPath permettant une liaison dynamique avec des produits commerciaux.

Java SE 24 est classé comme un release avec un support standard, des mises à jour seront publiées jusqu'à la prochaine version. Pour un support à long terme (LTS), il convient d'utiliser Java SE 21 ou Java SE 17, dont les mises à jour seront proposées jusqu'en 2031 et 2029 respectivement (accessibles au public jusqu'en 2028 et 2026). Le support étendu de la branche LTS de Java SE 8 se prolongera jusqu'en 2030, et pour Java SE 11 jusqu'en 2032. La prochaine version LTS sera la version d'automne Java SE 25.

Parmi les nouveautés proposées dans Java SE 24 :

• Un mode de travail génératif expérimental du ramasse-miettes Shenandoah est proposé, où les objets anciens et récemment créés sont traités séparément pour améliorer l'efficacité du nettoyage des objets avec une courte durée de vie. Ce nouveau mode offre une capacité de traitement plus prévisible, une résilience face aux variations de charge et une réduction de la consommation de mémoire lors du ramassage des déchets. Le planificateur Shenandoah vise à diminuer le temps d'arrêt pendant le ramassage des déchets en effectuant davantage de travaux en parallèle avec l'exécution des applications Java.
• Un support expérimental pour des en-têtes d'objets compacts a été implémenté dans la JVM HotSpot, la taille de ces en-têtes étant réduite sur les systèmes 64 bits de 96 à 64 bits (de 12 à 8 octets). La réduction de la taille des en-têtes permet de diminuer la taille du tas et d'améliorer l'efficacité de l'utilisation du cache.
• Dans le ramasseur de déchets G1, la mise en œuvre des barrières qui suivent l'accès de l'application à la mémoire a été simplifiée. Dans la nouvelle version, les opérations d'extension des barrières ont été déplacées à une étape de compilation ultérieure dans C2 JIT. Les tests effectués montrent que ce transfert permet de réduire les frais généraux dans le compilateur JIT C2 de 10 à 20 % selon l'application.
• Une API a été ajoutée pour l'utilisation des fonctions cryptographiques de dérivation de clé (KDF, key derivation function), permettant de générer des clés supplémentaires de longueur nécessaire à partir d'une clé secrète (par exemple, un mot de passe) et d'un ensemble de données arbitraire. L'API KDF est actuellement en statut préliminaire (preview).
• La possibilité de chargement et de liaison de classes à l'avance (Ahead-of-Time) a été ajoutée. Ce changement permet d'accélérer le démarrage de la JVM HotSpot en fournissant les classes utilisées dans l'application dans un état déjà chargé et lié. Lors de la première exécution de l'application, l'état de toutes les classes est mis en cache et utilisé pour accélérer le chargement lors des exécutions suivantes.
• Une API Class-File a été ajoutée pour l'analyse, la génération et la transformation des fichiers de classes Java.

  ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith("debug"))) { classBuilder.with(ce); } } });

• Une API Stream étendue a été ajoutée, prenant en charge la définition d'opérations intermédiaires personnalisées, qui peuvent être utiles lorsque les opérations intermédiaires intégrées existantes ne suffisent pas pour la transformation des données souhaitée. Les gestionnaires personnalisés se connectent via une nouvelle opération intermédiaire Stream::gather(Gatherer), qui traite les éléments du flux en appliquant à eux un gestionnaire défini par l'utilisateur. jshell> Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
• La quatrième mise en œuvre préliminaire des valeurs limitées (Scoped Values) a été proposée, permettant le partage de données immuables dans des flux et un échange efficace de données entre des sous-flux (les valeurs sont héritées). Les Scoped Values évoluent pour remplacer le mécanisme des variables locales au flux (thread-local variables) et sont plus efficaces lors de l'utilisation d'un très grand nombre de flux virtuels (des milliers et des millions de flux). La principale différence entre les Scoped Values et les variables locales au flux est que les premières sont enregistrées une fois, ne peuvent plus être modifiées par la suite et restent accessibles uniquement pendant l'exécution du flux.
• Le mécanisme de correspondance de modèle a été enrichi d'un support préliminaire pour l'utilisation de types primitifs (int, byte, char et autres types de base qui ne sont pas des objets) dans toutes les variantes des modèles, 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 neuvième mise en œuvre préliminaire de l'API Vector a été proposée, fournissant des fonctionnalités pour le calcul vectoriel, qui s'exécute en utilisant les instructions vectorielles des processeurs x86_64 et AArch64, permettant d'appliquer simultanément des opérations à plusieurs valeurs (SIMD). Contrairement aux capacités d'auto-vectorisation des opérations scalaires fournies par le compilateur JIT HotSpot, la nouvelle API permet de gérer explicitement la vectorisation pour le traitement parallèle des données.
• Un support pour la synchronisation des flux virtuels sans leur attachement (pinning) à des flux liés à la plateforme a été implémenté. Les flux virtuels dans une méthode ou expression synchronisée en état de blocage libèrent désormais leur flux de plateforme, permettant à d'autres flux virtuels de l'utiliser, ce qui augmente considérablement le nombre de flux virtuels disponibles et améliore l'évolutivité des applications utilisant le multi-threading.
• Un troisième pré-version de la fonctionnalité a été ajoutée, permettant de spécifier dans les constructeurs d'expressions avant l'appel de super(...), utilisé pour appeler explicitement le constructeur de la classe parente depuis le constructeur de la classe héritée, si ces expressions ne font pas référence à l'instance créée par le constructeur. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
• L'utilitaire jlink a introduit la prise en charge de la création d'images d'exécution sans utiliser de fichiers JMOD, ce qui permet de réduire la taille du JDK d'environ 25 %.
• Un deuxième pré-version de l'utilisation de l'expression «import module M» a été ajouté pour importer immédiatement tous les packages exportés par le module spécifié. Ce changement simplifie considérablement la réutilisation des bibliothèques de modules, permettant de connecter des bibliothèques et des classes sans définir leur emplacement dans la hiérarchie des packages. Par exemple, l'indication «import module java.base» conduira à l'importation de tous les 54 packages inclus dans le module java.base, qui auparavant auraient dû être mentionnés séparément («import java.io.*», «import java.util.*», etc.).
• Une quatrième pré-implémentation des classes implicitement déclarées et des instances anonymes de la méthode «main» a été ajoutée, dans laquelle on peut se passer des déclarations public/static, du passage d'un tableau d'arguments et d'autres entités liées à la déclaration de classe. // avant public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // maintenant on peut void main() { System.out.println("Hello, World!"); }
• Un quatrième pré-version de l'API pour la concurrence structurée (Structured Concurrency) a été proposé pour test, simplifiant le développement d'applications multithreads en traitant plusieurs tâches exécutées dans des threads différents comme un seul bloc.
• L'API KeyPairGenerator, Signature et KeyFactory a ajouté la prise en charge des algorithmes ML-KEM (CRYSTALS-Kyber) et ML-DSA (CRYSTALS-Dilithium), standardisés par l'Institut national des normes et de la technologie des États-Unis (NIST) et résistants aux attaques des ordinateurs quantiques. Ces algorithmes utilisent des méthodes de cryptographie basées sur la résolution de problèmes de théorie des réseaux, le temps de résolution de ceux-ci n'étant pas différent sur les ordinateurs ordinaires et quantiques.
• Dans le ramasse-miettes ZGC, le support du mode non génératif, qui ne séparait pas le traitement des objets « anciens » et « jeunes », a été supprimé. À partir de Java SE 23, le mode génératif ZGC est appliqué par défaut.
• Des avertissements concernant l'utilisation de l'API JNI (Java Native Interface) et de FFM (Foreign Function & Memory) ont été ajoutés afin de préparer les développeurs à la restriction d'accès à ces API en raison de l'activation, dans l'une des futures versions, d'un mode de préservation de l'intégrité, qui interdit par défaut l'interaction avec le code natif.
• Un avertissement s'affiche désormais lors de l'utilisation des méthodes d'accès à la mémoire externe (hors JVM) fournies par la classe sun.misc.Unsafe. Pour accéder à la mémoire hors tas (off-heap) et interagir avec du code externe, il est recommandé d'utiliser l'API VarHandle. Dans la version précédente, le support de sun.misc.Unsafe avait été déclaré obsolète.
• Le Security Manager a été désactivé, car il est devenu obsolète et inutilisé après l'abandon du support des plugins de navigateur. Le Security Manager a été classé comme obsolète dans Java 17. Il est prévu de supprimer complètement le code du Security Manager dans une prochaine version.
• Le code pour le support de la plateforme Windows 32 bits sur les systèmes x86 a été supprimé. Le port Java pour les systèmes x86 32 bits a été déclaré obsolète et est prévu pour suppression (le support de Linux sur les systèmes x86 32 bits sera également abandonné).

Il est également à noter la publication d'une mise à jour de la plateforme pour créer des applications avec une interface graphique JavaFX 24 et la nouvelle version de la machine virtuelle universelle GraalVM, qui prend en charge l'exécution d'applications en JavaScript (Node.js), Python, Ruby, R, dans tous les langages pour JVM (Java, Scala, Clojure, Kotlin) et dans les langages pour lesquels du bitcode LLVM peut être généré (C, C++, Rust). En plus du support de JDK 24, la nouvelle version de GraalVM a bénéficié d'optimisations pour les tâches liées à l'apprentissage automatique, d'une meilleure prise en charge de la compilation du bytecode Java en code machine, ainsi que d'un mécanisme SkipFlow pour réduire la taille des fichiers exécutables et diminuer le temps de compilation.

Source : opennet.ru