Après six mois de développement, Oracle a publié la plateforme Java SE 26 (Java Platform, Standard Edition 26), dont la mise en œuvre de référence utilise le projet open source OpenJDK. À l'exception de la suppression de certaines fonctionnalités obsolètes, Java SE 26 maintient la compatibilité avec les versions précédentes de la plateforme Java : la plupart des projets Java écrits auparavant fonctionneront sans modifications sous la nouvelle version. Des versions prêtes à l'installation de Java SE 26 (JDK, JRE et Server JRE) sont préparées pour Linux (x86_64, AArch64), Windows (x86_64) et macOS (x86_64, AArch64). La mise en œuvre de référence de Java SE 26, développée dans le cadre du projet OpenJDK, est entièrement open source sous licence GPLv2 avec des exceptions GNU ClassPath, permettant le lien dynamique avec des produits commerciaux.
Java SE 26 est classé parmi les versions avec un cycle de support standard, des mises à jour étant publiées jusqu'à la sortie de la prochaine version. Pour une branche de support à long terme (LTS), il convient d'utiliser Java SE 25, Java SE 21 ou Java SE 17, dont les mises à jour seront publiées jusqu'en 2033, 2031 et 2029 respectivement (en accès public jusqu'en septembre 2030, 2028 et 2026). Le support étendu de la branche LTS Java SE 8 se poursuivra jusqu'en 2030, tandis que Java SE 11 bénéficiera d'un support jusqu'en 2032.
Parmi les changements dans Java SE 26 (1, 2, 3, 4) :
- Un avertissement est émis lors de l'utilisation de la réflexion profonde pour modifier des champs marqués avec le mot-clé « final ». À l'avenir, il est prévu de désactiver par défaut les fonctionnalités non sécurisées du langage et, entre autres, de rendre les champs marqués comme finale totalement immuables, en supprimant les moyens de les modifier via la réflexion profonde (API Reflection).
- L'API Applet (java.applet.Applet*, javax.swing.JApplet) a été supprimée, utilisée pour exécuter des applications Java dans le navigateur. Cette API a perdu sa pertinence après la cessation du support du plugin Java pour les navigateurs et a été déclarée obsolète en 2021.
- La possibilité d'utiliser un cache préformé (AOT — ahead-of-time) avec tous les ramasseurs de déchets, y compris ZGC (Z Garbage Collector), a été implémentée. Ce changement implique le support d'un chargement séquentiel d'objets Java mis en cache en mémoire, en utilisant un format universel et indépendant des ramasseurs de déchets, au lieu d'un mappage direct dans des représentations de cache spécifiques en mémoire. L'utilisation du cache AOT réduit le temps de démarrage et accélère la phase de réchauffement (warmup) de la machine virtuelle HotSpot.
- Le client HTTP API a été mis à jour pour supporter le protocole HTTP/3, permettant aux applications et bibliothèques d'accéder aux serveurs via HTTP/3 après des modifications minimales du code.
- Les performances du ramasse-miettes G1 ont été améliorées grâce à une réduction des blocages pour synchroniser les threads d'application avec les threads du ramasse-miettes.
- Une seconde version préliminaire de l'API pour l'encodage et le décodage d'objets avec des clés cryptographiques, des certificats et des listes de certificats révoqués a été proposée, utilisant le format PEM (Pivacy-Enhanced Mail).
- Une sixième version préliminaire de l'API pour la concurrence structurée (Structured Concurrency) a été proposée pour test, simplifiant le développement d'applications multithread en traitant plusieurs tâches exécutées dans différents threads comme un seul bloc.
- Une deuxième version préliminaire de l'API Lazy Constants a été ajoutée pour travailler avec des objets contenant des données immuables, traitées dans la JVM comme des constantes. À ces objets sont appliquées des optimisations de performance semblables à celles des champs avec le mot-clé «final». Contrairement à «final», la nouvelle API dissocie la création de valeurs constantes de leur initialisation, garantissant que la valeur ne peut être initialisée qu'une seule fois, réduisant le temps de démarrage des programmes et permettant d'appliquer dans le code utilisateur des optimisations de pliage de constantes (constant-folding) qui étaient auparavant réservées au code interne du JDK. class Application { // Était: // static final UserService USERS = new UserService(); // Maintenant, on peut: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
- Dans le mécanisme de correspondance de motif, une quatrième option préliminaire a été proposée pour l'utilisation de types primitifs (int, byte, char et autres types de base qui ne sont pas des objets) dans tous les types de 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 … }
- Une onzième implémentation test de l'API Vector a été proposée, fournissant des fonctions pour les calculs vectoriels, qui sont effectués à l'aide des instructions vectorielles des processeurs x86_64 et AArch64 et permettent 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.
De plus, Oracle a annoncé le projet Detroit, qui se développera dans le cadre d'OpenJDK et vise à améliorer la portabilité entre Java, JavaScript et Python. Dans le cadre de ce projet, il est prévu de permettre l'intégration dans le runtime JVM avec le moteur JavaScript V8 et l'interpréteur CPython. Auparavant, Oracle avait déjà développé le moteur JavaScript Nashorn, fonctionnant au-dessus de la machine virtuelle JVM, mais a arrêté le projet en raison de la difficulté à développer une implémentation distincte de JavaScript dans un contexte où l'écosystème principal est lié au moteur V8.
Il convient également de noter la publication d'une mise à jour de la plateforme pour la création d'applications avec interface graphique JavaFX 26. Dans les prochaines heures, la sortie de la machine virtuelle universelle GraalVM 26, prenant en charge l'exécution d'applications en JavaScript (Node.js), Python, Ruby, R, ainsi que tous les langages pour JVM (Java, Scala, Clojure, Kotlin) et les langages pour lesquels un bitcode LLVM peut être généré (C, C++, Rust) est également attendue.
Source : opennet.ru
