Sortie de Java SE 15

Après six mois de développement, la société Oracle une mise à jour du micrologiciel et un SDK pour l'environnement SGX, dans lequel elle a tenté de bloquer l'attaque par contournement. Les méthodes proposées d'attaque ne sont actuellement applicables qu'aux processeurs Intel, mais il n'est pas exclu que LVI soit adapté à d'autres processeurs susceptibles d'être sujets aux attaques de type Meltdown. la plateforme Java SE 15 (Java Platform, Standard Edition 15), dont l'implémentation de référence est basée sur le projet ouvert OpenJDK. Java SE 15 maintient la compatibilité avec les versions précédentes de la plateforme Java, tous les projets Java précédemment écrits fonctionneront sans modifications sous la nouvelle version. Les distributions prêtes à l'emploi de Java SE 15 (JDK, JRE et Server JRE) préparés sont disponibles pour Linux (x86_64), Windows et macOS. La référence développée dans le cadre du projet OpenJDK Java 15 est entièrement ouverte sous la licence GPLv2 avec des exceptions GNU ClassPath, permettant le liaison dynamique avec des produits commerciaux.

Java SE 15 est classé parmi les versions avec un cycle de support standard, les mises à jour seront publiées jusqu'à la prochaine version. Pour une branche à long terme (LTS), il convient d'utiliser Java SE 11, dont les mises à jour seront fournies jusqu'en 2026. L'ancienne branche LTS Java 8 sera supportée jusqu'en décembre 2020. La prochaine version LTS est prévue pour septembre 2021. Rappelons qu'à partir de Java 10, le projet a adopté un nouveau processus de développement, avec un cycle de publication plus court. Les nouvelles fonctionnalités sont désormais développées dans une branche principale constamment mise à jour, où sont intégrés les changements prêts et dont sont dérivées des branches pour la stabilisation des nouvelles versions tous les six mois.

De innovations Java 15 est possible notez:

• Intégré support de l'algorithme de création de signature numérique EdDSA (Edwards-Curve Digital Signature Algorithm RFC 8032). L'implémentation proposée d'EdDSA est indépendante des plateformes matérielles, protégée contre les attaques par canaux latéraux (garantissant un temps de calcul constant) et surpasse l'implémentation existante d'ECDSA, écrite en C, tout en offrant un niveau de sécurité équivalent. Par exemple, EdDSA utilisant une courbe elliptique avec une clé de 126 bits montre des performances comparables à celles d'ECDSA avec la courbe elliptique secp256r1 et une clé de 128 bits.
• Ajouté support expérimental des classes et interfaces scellées (« sealed »), qui ne peuvent pas être utilisées par d'autres classes et interfaces pour l'héritage, l'extension ou la redéfinition de l'implémentation. Les classes scellées offrent également un moyen plus déclaratif d'en limiter l'utilisation, comparé aux modificateurs d'accès, en énumérant explicitement les sous-classes autorisées à être étendues.

  package com.example.geometry;

  public sealed class Shape
  permet com.example.polar.Circle,
  com.example.quad.Rectangle,
  com.example.quad.simple.Square {…}

• Ajouté prise en charge des classes cachées qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. L'utilisation principale des classes cachées est dans les frameworks qui génèrent dynamiquement des classes à l'exécution et les utilisent indirectement, via réflexion. De telles classes ont généralement un cycle de vie limité, et donc leur maintien pour l'accès à partir de classes générées statiquement n'est pas justifié et ne ferait qu'augmenter la consommation de mémoire. Les classes cachées permettent également de se passer de l'API non standard sun.misc.Unsafe::defineAnonymousClass, qui est prévue pour suppression à l'avenir.
• Le ramasse-miettes ZGC (Z Garbage Collector) a été stabilisé et reconnu comme prêt pour une utilisation généralisée. ZGC fonctionne en mode passif, minimisant autant que possible les délais dus au ramassage des déchets (le temps d'arrêt lors de l'utilisation de ZGC ne dépasse pas 10 ms) et peut fonctionner avec des tas aussi petits qu'avec d'énormes tas, allant de plusieurs centaines de mégaoctets à plusieurs téraoctets.
• Stabilisé et reconnu comme prêt pour une utilisation généralisée
  ramasse-miettes Shenandoah, fonctionnant avec des pauses minimales (Low-Pause-Time Garbage Collector). Shenandoah a été développé par Red Hat et se distingue par l'utilisation d'un algorithme qui réduit le temps d'arrêt pendant le ramassage des déchets en nettoyant parallèlement l'exécution des applications Java. La taille des retards introduits par le ramasse-miettes est prévisible et ne dépend pas de la taille du tas, c'est-à-dire que pour des tas de 200 Mo et de 200 Go, les retards seront identiques (ne dépassent 50 ms et s'inscrivent généralement dans 10 ms);
• La prise en charge des des blocs de texte — nouvelles formes de littéraux de chaînes, permettant d'inclure dans le code source des données textuelles multi-lignes sans avoir besoin d'échapper les caractères et en conservant le formatage d'origine du texte dans le bloc. Le bloc est encadré par trois guillemets doubles.

  Par exemple, au lieu du code

  String html = «<HTML>» +
  «\n\t» + «<BODY>» +
  «\n\t\t» + «<H1>\»Java 15 est là!\»<\/H1>» +
  «\n\t» + «<\/BODY>» +
  «\n» + «<\/HTML>»;

  On peut indiquer :

  String html = «»»
  <HTML>
  <BODY>
  «<H1>»Java 15\
  est ici!»<\/H1>
  <\/BODY>
  <\/HTML>»»»;

• Révisé API Legacy DatagramSocket. Les anciennes implémentations de java.net.DatagramSocket et java.net.MulticastSocket ont été remplacées par une mise en œuvre moderne, plus facile à déboguer et à entretenir, et compatible avec les flux virtuels développés dans le cadre du projet Loom. En cas de possible incompatibilité avec le code existant, l'ancienne implémentation n'a pas été supprimée et peut être réactivée à l'aide de l'option jdk.net.usePlainDatagramSocketImpl.
• Une deuxième implémentation expérimentale a été proposée la correspondance avec un modèle dans l'opérateur «instanceof», qui permet de définir immédiatement une variable locale pour accéder à la valeur vérifiée. Par exemple, on peut écrire immédiatement «if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}» sans déclaration explicite de «String s = (String) obj».

  Avant :

  if (obj instanceof Group) {
  Group group = (Group) obj;
  var entries = group.getEntries();
  }

  Maintenant, il est possible de se passer de la définition «Group group = (Group) obj» :

  if (obj instanceof Group group) {
  var entries = group.getEntries();
  }

• Un soutien la deuxième implémentation expérimentale du mot-clé «record«, fournissant une forme compacte de définition de classes, permettant d'éviter la définition explicite de divers méthodes de bas niveau, telles que equals(), hashCode() et toString(), lorsque les données sont uniquement stockées dans des champs, dont le comportement ne change pas. Lorsque des implémentations types des méthodes equals(), hashCode() et toString() sont utilisées dans une classe, il est possible de se passer de leur définition explicite :

  public record BankTransaction(LocalDate date,
  double amount,
  String description) {}

  Cette déclaration entraînera l'ajout automatique des implémentations des méthodes equals(), hashCode() et toString() en plus du constructeur et des méthodes contrôlant la modification des données (getter).

• Proposé deuxième version préliminaire de l'API Foreign-Memory Access, permettant aux applications Java d'accéder de manière sécurisée et efficace à des zones de mémoire en dehors du tas Java, à l'aide de nouvelles abstractions telles que MemorySegment, MemoryAddress et MemoryLayout.
• Le support et la technique d'optimisation Biased Locking a été déclarée obsolète, utilisée dans HotSpot JVM pour réduire les frais liés aux verrous. Cette technique est devenue obsolète sur les systèmes avec des instructions atomiques, fournies par les processeurs modernes, et trop difficile à maintenir en raison de sa complexité.
• Déclaré mécanisme obsolète Activation RMI, qui sera supprimé dans l'une des futures versions. Il est à noter que l'Activation RMI est devenue obsolète, a été rétrogradée en option depuis Java 8 et est presque jamais utilisée dans la pratique moderne.
• Supprimé moteur JavaScript Nashorn, qui a été déclaré obsolète dans Java SE 11.
• la méthode non standard ports pour le système d'exploitation Solaris et les processeurs SPARC (Solaris/SPARC, Solaris/x64 et Linux/SPARC). La suppression des ports mentionnés permettra à la communauté d'accélérer le développement de nouvelles fonctionnalités d'OpenJDK, sans perdre de temps à maintenir des spécificités liées à Solaris et SPARC.

Source : opennet.ru