Sortie de Java 15

java 15

Oracle a annoncé l’arrivée de Java 15 et la disponibilité de Oracle OpenJDK 15 (Communautaire) et Oracle JDK 15 (version entreprise). L’annonce a été faite le 15 septembre dernier (2020).

Java reste sur un rythme effréné d’une release tous les 6 mois. Ce rythme a été instauré à partir de Java 9 en 2014. Depuis, nous avons eu droit à une nouvelle release tous les 6 mois.

Pour rappel, Java 15 n’est pas une version LTS. Son support s’arrêtera en mars 2021.

Depuis la version 8, Java avance à grands pas, et on ne peut que s’en réjouir. Nous allons revenir dans ce billet sur les principales features de cette version.

Text blocs (blocs de texte) – (JEP 378)

Cette feature permet de créer des chaînes de caractères sur plusieurs lignes. Cela permet d’avoir un code plus lisible, surtout quand il s’agit d’écrire du JSON, XML ou du SQL dans une String, comme dans l’exemple ci-dessous:

String example = """
     select u.id
     from users u
     where u.age > 25 """;

Sealed classes (litéralement classes scellées) – JEP 360

Il s’agit de la JEP 360. Il est possible de définir une classe ou une interface comme étant scellée, en contrôlant quelles classes ou interfaces peuvent étendre (hériter de) celle-ci.

Attention: ce n’est en aucun cas un remplacement des access modifiers ou un remplacement du mot clé “final”.

public abstract sealed class Shape permits Circle {

    public abstract Point getCenter();

    public non-sealed class Circle extends Shape {

        private Point center;

        public Circle(){
            this.center = new Point(0, 0);
        }

        public Circle(int x, int y){
            this.center = new Point(x, y);
        }

        @Override
        public Point getCenter() {
            return center;
        }
    }
}

Seule la classe Circle peut hériter de la classe Shape.

Hidden classes (litéralement classes cachées) – JEP 371

Ce sont des classes qui ne peuvent pas être accédées par le byte code des autres classes. Autrement dit, ces classes ne sont pas accessibles par reflection. Les hidden classes sont destinées à une utilisation dans l’écriture des frameworks qui utilisent la reflection pour générer des classes au runtime. Cela permet essentiellement aux frameworks de définir des classes qui ne sont pas “découvrables” à travers la réflection par d’autres classes, de telle sorte que ces dernières ne soient pas liées à d’autres classes. Cela permet notamment un unloading “agressif” des hidden classes.

Amélioration de instanceof : pattern matching – JEP 375

Cette feature est toujours en preview (depuis Java 14). Cela permet de passer au type voulu de façon plus élégante, en évitant le cast. A partir du moment où l’on écrit :

a instanceof SomeClass sc

Nous pouvons parfaitement utiliser la variable sc dans la suite de la condition ou du bloc (if):

if(a instanceif SomeClass sc && sc.method1(...) ) {
	sc.method2(...)
}

Les records – JEP 384

Déjà présents dans la JDK 14 en preview, les records permettent de créer des “data class” ou des tuples. Les records ont la particularité d’être immuables (immutables) et implémentent par construction, les accessors, “equals(…)”, “hashcode(…)” et “toString(…)”. Ainsi, en déclarant:

record Point(int x, int y) { }

Le compilateur comprend :

record Point(int x, int y) { 
    // Implicitly declared fields
    private final int x;
    private final int y;

    // Implicitly declared accessors
    Public x(){ return x}
    Public y(){ return x}

    // Implicitly declared canonical constructor
    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    // Implicitly declared equals, hsashcode and toString methods
    public boolean equals(Object o) { 
        if (!(o instanceof Point)) return false;
        Point other = (Point) o;
        return other.x == x && other.y = y;
    }

    public int hashCode() {
        return Objects.hash(x, y);
    }

    public String toString() { 
        return String.format("Point[x=%d, y=%d]", x, y);
    }
}

Suppression de Nashorn – JEP 372

Le moteur Javascript Nashorn, une implémentation complète de ECMAScript 5.1, été introduit dans le JDK 8. Il a été déprécié (depricated) dans le JDK 11, et supprimé dans le JDK 15. La suppression est due à la difficulté de maintien / maintenance de Nashorn, au vu de l’évolution rapide d’EcmaScript.

Suppression du support Solaris et Sparc – JEP 381

Déprécié depuis le JDK 14, le code spécifique aux architecture SOLRIS et SPARC a été supprimé dans la JDK 15. Ceci dans le but de faire avancer plus vite les projets en développement (Loom, Valhalla …). Autrement, il faudrait beaucoup plus d’efforts d’adaptation et de changements à apporter au code spécifique à ces architectures.

Dépréciation de RMI Activation – JEP 385

C’est un mécanisme introduit dans le JDK 7, qui permet de s’assurer que les services sont disponibles (crash recovery, persistent references, on demand). Avec l’évolution des web services, des containers et des orchestrateurs, ce mécanisme est jugé obsolète. RMI Activation est donc déprécié dans la JDK 15, pour une future suppression. Il faut noter que cela ne modifie en rien le reste de RMI et ce n’est point une dépréciation de RMI.

Désactivation et dépréciation du Biased Lock – JEP 374

Le biased locking est une technique de locking qui permet de réduire le coût du locking. Les performances de cette technique, ayant fait ses preuves dans le passé, n’est plus utile, avec l’avènement de nouvelles architectures, des API et des nouvelles façons d’écrire le code.

A noter que cette technique est désactivée, mais peut être réactivée avec le flag -XX:+UseBiasedLocking

Nouvelle implémentation de l’API DatagramSocket – JEP 373

Nouvelle implémentation plus modernes des API java.net.DatagramSocket et java.net.MulticastSocket. L’idée étant de simplifier l’utilisation de ces API dans les futures projets, tel que Loom (virtual threads).

API d’accès à la mémoire externe (Foreign-Memory Access API) – JEP 383

Introduite dans la JDK 14 en mode incubation, cette fonctionnalité est reconduite en incubation dans la JDK 15 avec quelques améliorations. Cette feature permet aux programmes Java d’accéder à de la mémoire en dehors du Heap Java.

Implémentation de l’algorithme EdDSA – JEP 339

Edwards-Curve Digital Signature Algorithm est un algorithme moderne de signature électronique. Ce schéma, décrit dans la RFC 8032, a été implémenté dans le JDK 15.

ZGC en production – JEP 377

Etant en mode expérimental depuis la JDK 11. Il est désormais disponible sans devoir utiliser le flag XX:+UnlockExperimentalVMOptions

ZGC est un Garbage Collector à faible latence. C’est-à-dire avec des temps de pause de l’ordre de quelques millisecondes, et pouvant gérer un heap de 8Mo jusqu’à 16To. A noter que le GC par défaut reste G1.

Shenandoah GC en production – JEP 379

Etant en mode expérimental depuis la JDK 12. Il est désormais disponible sans devoir utiliser le flag XX:+UnlockExperimentalVMOptions. Au même titre que ZGC, Shenandoah GC est une Garbage Collector à faible latence. Il s’exécute également de façon concurrente, autrement dit en parallèle de l’exécution du code du programme.

 

Oracle met les bouchées doubles afin de garder un rythme de développement et d’innovation élevé, dans le but de faire face à la concurrence d’autres langages, tel que Kotlin. D’ailleurs, nombre de fonctionnalités ajoutées dans les dernières versions du JDK sont inspirées directement de ce langage (Sealed classes), et d’autres à venir (Loom project).

Software Engineer & CEO @TechInstinct