Tutoriel pour découvrir les nouveautés de Java 15

Une classe scellée est une classe spécifique qui ne peut pas s'étendre (extends) ou être implémentée (implements) sauf

• Si c'est déclaré explicitement en utilisant le mot clé sealed au niveau de la classe
• En utilisant le mot clé permits pour les classes autorisées

JDK 15 améliore le langage de programmation Java avec des classes et des interfaces scellées. Les classes et interfaces scellées limitent les autres classes ou interfaces qui peuvent les étendre ou les implémenter. L'extension ou l'implémentation doit être partielle et pas totale. Elle est partielle via l'utilisation du mot clé permits qui donne un sous-ensemble de classe ou d'interface autorisé à enrichir la définition initiale.

Dans l’exemple ci-dessous, nous déclarons que la forme de classe autorise trois sous-classes spécifiques :

package com.example.geometry;
public sealed class Shape
permits Circle, Rectangle, Square {...}

JDK 15 améliore le langage de programmation Java avec l’appariement des motifs pour l’opérateur instanceof. La correspondance des motifs permet d’exprimer une logique commune dans un programme, à savoir l’extraction conditionnelle de composants à partir d’objets, de manière plus concise et sécuritaire. Il s’agit d'une fonctionnalité d’aperçu dans JDK 15.

Le but de cette fonctionnalité est de se débarrasser du code répétitif et standard

Souvent, nous devons faire quelque chose de similaire à l'exemple dessous :

if (obj instanceof Integer) {
    Integer i = (Integer) obj;
    //faire quelque chose avec i en tant que Integer
} else {
    Object obj = obj;
    //faire quelque chose avec obj en tant qu'Objet
}

Cela est sujet à des erreurs et un peu répétitif. Il y a des plusieurs déclarations de Integer ici. À partir de JDK 15, avec cette fonctionnalité, nous pouvons faire le suivant:

if (obj instanceof Integer i) {
    // faire quelque chose avec i
} else {
    // impossibilité de faire quelque chose avec i ici
}

Les travaux futurs sur ce JEP (JDK enhancement proposal/JDK proposition d'amélioration) incluront la même logique pour d’autres instructions comme l’instruction de switch.

fonctionnalité d’aperçu

JEP

2-3-1. Situation avant cette fonctionnalité▲

final class Person {
    public final String firstname;
    public final String lastname;

    public Person(String firstname, String lastname) {
        this.firstname = firstname;
        this.lastname = lastname;
    }
    // ici on doit implementer equals, hashCode, toString
    // il s'agit du code répétitif et standard }

2-3-2. Lombok: une bibliothèque utile▲

import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.Setter;
@Getter
@Setter
@AllArgsConstructor(access = AccessLevel.PUBLIC)
    public class Person {
    public final String firstname;
    public final String lastname;
  }

2-3-3. La nouvelle solution▲

record Person(String firstname, String lastname) { }

L'API d'accès à la mémoire externe (Foreign memory access API) permet aux programmes Java d’accéder de manière sûre et efficace à la mémoire externe en dehors du Java heap. Le but principal est d'éviter le coût et l'imprévisibilité liée au garbage collection (spécialement quand il y a de larges caches). Cette fonctionnalité ressemble à la fonction malloc du langage C où on peut demander l'allocation de la mémoire.

Un autre objectif est de partager la mémoire dans des processus multiples. Cette fonctionnalité intègre trois abstractions:

• MemorySegment est une région de mémoire contiguë ;
• MemoryAddress modélise une adresse ;
• MemoryLayout est une description du contenu d'un segment.

Voici un exemple d'un MemorySegment associé à buffer de mémoire de 100 octets:

try (MemorySegment segment = MemorySegment.allocateNative(100)) {
...
  }

Dans la cryptographie à clé publique, Edwards-Curve Digital Signature Algorithm est un schéma mathématique pour vérifier l’authenticité des messages numériques.

Cette fonctionnalité implémente des signatures cryptographiques à l’aide de l’algorithme de signature numérique Edwards-Curve (EdDSA) tel que décrit par RFC 8032.

EdDSA est demandé grâce à sa sécurité et sa performance améliorée. EdDSA est utilisé dans d'autres bibliothèques crypto comme OpenSSL et BoringSSL.

//exemple : générer une paire de clés et signer
KeyPairGenerator kpg = KeyPairGenerator.getInstance(« Ed25519 »);
KeyPair kp = kpg.generateKeyPair();
// algorithme est Ed25519
Signature sig = Signature.getInstance(« Ed25519 »);
sig.initSign(kp.getPrivate());
sig.update(msg);
byte[] s = sig.sign();

// example: utiliser KeyFactory pour construire une clé publique
KeyFactory kf = KeyFactory.getInstance("EdDSA");
boolean xOdd = ...
BigInteger y = ...
NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519");
EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y));
PublicKey pubKey = kf.generatePublic(pubSpec);

RFC 8032

Les classes cachées sont des classes qui ne peuvent pas être utilisées directement par le bytecode d’autres classes. Les classes cachées sont destinées à être utilisées par des frameworks qui génèrent des classes au moment de l’exécution et les utilisent indirectement, via la réflexion. Une classe cachée peut être définie comme un membre d’un nid de contrôle d’accès (Nest-Based Access Control) et peut être déchargée indépendamment des autres classes.

La différence la plus importante est dans la création d'une classe cachée. Pour créer une classe normale on invoque ClassLoader::defineClass. Par contre une classe cachée est créée par l'invocation du Lookup::defineHiddenClass. Ça provoque le JVM à dériver la classe cachée depuis les octets fournis, lier la classe cachée, et retourner un objet lookup qui fournit l'accès via la réflexion à la classe cachée.

Nid de contrôle d’accès (Nest-Based Access Control)

Ce JDK ajoute des blocs de texte au langage Java. Un bloc de texte est un littéral de chaîne multiligne qui évite la nécessité de la plupart des séquences d’échappement, formate automatiquement la chaîne d’une manière prévisible et donne au développeur le contrôle sur le format lorsque vous le souhaitez.

En Java, le fait d'embarquer un snippet de HTML, SQL, XML ou JSON dans un littéral de chaîne de caractères nécessite souvent une édition significative avec de caractères d'échappement et concaténation pour qu'il puisse être compilé.

Les blocs de texte offrent une approche plus simple à ce problème décrit ci-dessous :

En utilisant un string "une-dimension"

String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Bonjour les amis de developpez.net!</p>\n" +
              "    </body>\n" +
              "</html>\n";
En utilisant un bloc de text "deux-dimensions"

String html = """
              <html>
                  <body>
                      <p>Bonjour les amis de developpez.net!</p>
                  </body>
              </html>
              """;

Le moteur de script Nashorn JavaScript et les API, ainsi que l ’outil jjs sont supprimés. Le moteur, les API et l’outil ont été déconseillés (deprecated) pour être retirés en Java 11 avec l’intention de les supprimer dans une version ultérieure. La raison en était que l’équipe considérait qu’il était difficile de les maintenir.

Suppression du code source et du support de compilation des ports Solaris/SPARC, Solaris/x64 et Linux/SPARC. Ces ports ont été depreciés pour suppression dans JDK 14 avec l’intention expresse de les supprimer dans une future version.

Déprécier le mécanisme d’activation RMI pour la suppression future. RMI Activation est une partie obsolète de RMI qui est facultative depuis Java 8. Aucune autre partie du RMI ne sera dépréciée.

Mécanisme d’activation RMI

Cette fonctionnalité remplace les anciennes implémentations des API

• java.net.DatagramSocket
• java.net.MulticastSocket

par des implémentations plus simples et plus modernes qui sont faciles à maintenir et à déboguer. Les nouvelles implémentations seront faciles à adapter.

Cette fonctionnalité désactive le verrouillage biaisé (biased locking) par défaut et déprécie toutes les options de ligne de commande associées.

Le verrouillage biaisé est utilisé si les objets ne sont verrouillés que par un thread. Dans ce cas-là, la JVM peut effectuer une optimisation et « biaiser » cet objet vers ce thread de telle sorte que les opérations atomiques ultérieures sur l'objet n'entraînent aucun coût de synchronisation.

Les gains de performance observés dans le passé sont beaucoup moins évidents aujourd’hui. Ce fait combiné à la difficulté de le maintenir a conduit à cette décision de désactivation et dépréciation du verrouillage biaisé.

Le projet ZGC a réellement commencé avec Java 11. Il s’agit d’un sujet complexe qui devait être introduit progressivement pour permettre aux utilisateurs de fournir leurs commentaires et d’avoir des bogues corrigés. En Java 15, cette fonctionnalité est considérée comme complète et prête à être utilisée en mode production.

ZGC peut être activé à l’aide des options de ligne de commande -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

Cette fonctionnalité offre ce collecteur d’ordures maintenant, mais ne change pas la valeur par défaut qui resteG1.

Semblable à ZGC ici Shenandoah est un éboueur qui est prêt pour l'environnement de production. Il a été introduit comme expérimental en Java 12.

Il peut être activé avec xx:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC. Cette fonctionnalité conserve le collecteur d’ordures G1 par défaut.