On s’y est habitué : une nouvelle version du JDK… et l’API Vector qui reste en phase d’incubation.

Pas d’exception avec Java 27, arrivé ce 15 septembre. On en restera de toute façon à ce stade aussi longtemps que les briques de Project Valhalla ne seront pas passées en preview.

Project Valhalla est censé réconcilier l’expressivité de la programmation orientée objet avec les performances et la compacité des types primitifs. Cela passe notamment par les value objects. Ils n’ont pas identité propre (absence d’en-tête et de verrou de moniteur, entre autres). Cela permet d’optimiser leur encodage en mémoire et dans les registres CPU. Un avantage pour le calcul vectoriel intensif.

Généralisation des en-têtes compacts…

En attendant, Java 27 concrétise l’activation par défaut des en-têtes d’objets compacts au sein de la JVM HotSpot sur les architectures 64 bits. Ils passent de 12 à 8 octets – dont 4 réservés aux besoins de Project Valhalla. Oracle annonce une diminution d’environ 15 % du nombre de cycles GC. Et jusqu’à 10 % de temps gagné sur des benchmarks de parsing JSON fortement parallèles. Amazon exploite déjà ces en-têtes en production sur des centaines de services. SAP les activés sur SapMachine, son fork d’OpenJDK.

… du ramasse-miettes G1…

Concernant justement le ramasse-miettes : G1 devient le collecteur par défaut sur tous les environnements d’exécution. Jusque-là, il ne l’était pas sur les environnements disposant d’un seul cœur CPU ou de moins de 1792 Mo de mémoire physique. Le voilà désormais compétitif sur les débits comme sur l’empreinte mémoire, tout en conservant son avantage intrinsèque sur les temps de pause.

… et du masquage des données sensibles en mémoire

Autre élément stabilisé avec Java 27 : le masquage automatique des données sensibles dans les enregistrements du JFR. L’opération se fait en mémoire. Objectif : éviter que des secrets persistent dans les fichiers temporaires lors d’un crash JVM ou filtrent lors d’un streaming d’événements à distance. L’alternative regex a été rejetée à deux titres. D’une part, parce que l’API java.util.regex ralentirait le démarrage de la JVM. De l’autre, parce que les bibliothèques C++ peuvent lever des exceptions, interdites dans HotSpot.

Trois schémas hybrides post-quantiques pour TLS

Il y a aussi du nouveau sur le chiffrement. En l’occurrence, la prise en charge des échanges de clés hybrides post-quantiques pour le protocole TLS 1.3. Elle exploite les fondations déjà intégrées dans le JDK, à commencer par l’API KEM (Java 21) et l’algo ML-KEM (Java 24). Au menu, trois schémas, tous décrits dans la RFC 10024.

Schéma hybride	Algorithme classique (ECDHE)	Algorithme post-quantique	Statut par défaut
X25519MLKEM768	X25519	ML-KEM-768	Activé et prioritaire par défaut
SecP256r1MLKEM768	Curve secp256r1	ML-KEM-768	Optionnel (non actif par défaut)
SecP384r1MLKEM1024	Curve secp384r1	ML-KEM-1024	Optionnel (non actif par défaut)

Une API pour l’encodage PEM

Le JDK comporte aussi une API pour encoder et décoder les objets cryptographiques vers et depuis le standard de facto qu’est le format PEM (Privacy-Enhanced Mail, RFC 7468). C’en est la troisième préversion. Elle ajoute en particulier la gestion des paires de clés chiffrées (méthodes pour déchiffrer des textes PKCS#8 contenant également une clé publique) et une classe CryptoException qui indique les échecs de traitement.
Plusieurs pistes alternatives ont été étudiées. Dont une consistant à étendre l’API EncodedKeySpec avec une sous-classe qui aurait encapsulé le texte PEM et permis la conversion vers ou depuis les spécifications habituelles de clés. Option rejetée faute de gérer certificats et listes de révocation. N’a pas non plus été suivie la piste consistant à ajouter des méthodes d’encodage dans les classes KeyFactory et CertificateFactory. Essentiellement en raison de la complexité asymétrique, les clés existant sous de multiples représentations et formats.

3^e préversion pour LazyConstant, 7^e pour la concurrence structurée

Java 27, c’est également une nouvelle préversion (la 7^e) de l’API de concurrence structurée. Elle doit simplifier l’écriture du code multithread et en accroître la robustesse en traitant des groupes de sous-tâches concurrentes comme une unité de travail atomique.
Cette nouvelle révision refond la gestion des timeouts. Elle affine par ailleurs la gestion des exceptions dans les joiners.

L’API LazyConstant en est quant à elle à sa troisième preview. Sa promesse : optimiser l’usage des ressources en permettant de différer l’initialisation de données immuables.
Cette révision supprime les méthodes de bas niveau isInitialized() et orElse() pour éviter les contournements contraires à l’esprit de l’API.

Illustration © iuriimotov – Adobe Stock

The post Java 27 : en attendant l’API Vector, des avancées cryptographiques appeared first on Silicon.fr.

En mai 1992, l'armée yougoslave a fait exploser 56 tonnes d'explosifs pour détruire la base aérienne souterraine de Željava, l'un de ses plus grands et plus coûteux projets militaires jamais construits. Cette forteresse, creusée dans la montagne pendant deux décennies, censée survivre à une attaque nucléaire, a disparu en une seule nuit. Trois décennies plus tard, le site reste un fantôme miné et inaccessible.