Java 17 vient de sortir, du coup je vous fais un petit récap des nouveautés qui me semblent importantes. En sachant que cette nouvelle version de Java apporte peu de nouveauté, surtout des bases pour des travaux à venir, ainsi que beaucoup de suppression ou dépréciation d'API.

Sealed class

La seule vraie nouveauté notable quand on fait du Java 17 est l'ajout des sealed class. C'est une notion qui était totalement absente jusque-là.

Les sealed class ou classes scellées, sont un moyen d'empêcher l'extension d'une classe en dehors de certaines implémentations qu'on aura au préalable identifié. Jusqu'à Java 16 on pouvait seulement étendre une classe ou empêcher totalement l'extension (via le mot clé final).

On pourra maintenant écrire :

public abstract sealed class Shape
    permits Circle, Rectangle, Square {
    abstract getArea();
}

Ici seules les classes Circle, Rectangle et Square pourront étendre la classe. Si on essaie de créer une classe Triangle qui étend Shape, on aura une erreur de compilation.

Les classes scellées peuvent être pratiques pour délimiter les contours d'une API quand on sait que ça pourrait poser problème si une extension était effectuée par le client, mais en l'état on a peu d'usage concret.

Pattern Matching for switch

Pour l'instant cette fonctionnalité est en preview. Donc la syntaxe pourrait un peu évoluer dans le futur si elle ne convient pas pour certains usages.

L'idée ici est de pouvoir faire du pattern matching sur les types via des switch. On pourra écrire :

static String getWidth(Shape shape) {
    return switch (shape) {
        case Circle c    -> c.getDiameter();
        case Rectangle r -> r.getWidth();
        case Square s    -> s.getWidth();
    };
}

Dans mon exemple, j'ai repris la classe scellée dont je parlais au point précédent ce qui me permet d'omettre le default du switch, car il gère tous les cas possibles. Si Shape n'était pas une classe scellée il aurait fallu ajouter le cas par défaut pour que tout fonctionne.

J'en avais déjà un peu parlé dans mon REX d'un meetup avec José Paumard, le pattern matching est le futur de Java et va ouvrir beaucoup de possibilité et d'expressivité au langage.

Les packages internals plus fortement encapsulés

Il fallait s'y attendre, les modules Jigsaw continu d'être appliqué plus strictement sur Java. On pouvait jusqu'à il y a peu ne pas s'en occuper pour beaucoup d'API du JDK et on pouvait aller mettre le nez sans souci dans les packages internes, mais ce n'est plus possible. Une très grosse partie des packages internes n'est maintenant plus open et on a plus de paramètre ou configuration pour passer outre.

La liste des packages concernés est disponible ici : https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-strongly-encapsulated. De mon côté je retiens surtout : java.awt, java.swing, java.time, javax.crypto, java.util et java.nio (et quelques sous packages de ceux-ci).

Ce qui change comparé à Java 16 c'est qu'on ne peut plus demander à relâcher l'encapsulation pour ces packages. Maintenant on est obligé d'en tenir compte. Par contre, ça ne veut pas dire que ces packages ne sont plus du tout disponibles, jusque certaines classes et/ou interface qu'on pouvait utiliser (faute de pouvoir les masquer aux développeurs) ne peuvent plus l'être. C'était de toutes façons des classes qu'il n'était pas conseillé d'utiliser, donc normalement ce changement devrait avoir peu d'impact sur nos codes bases.

Déprécation d'API : Security Manager et Applet API

Je pense que ça ne devrait choquer personne de voir ces API supprimées dans le futur. Les Applets sont complètement dépassés par les standard des navigateurs. Le Security Manager n'est pratiquement jamais utilisé.

À noter que le Security Manager ne sera pas supprimé sans alternatives. Je ne détaillerais pas ici, mais la JEPS contient beaucoup de proposition pour remplacer l'usage du Security Manager par d'autres techniques ou API.

Au revoir AOT/JIT-compiler et RMI Activation

Ici on est à l'étape d'après la dépréciation : la suppression.

La possibilité de compiler en AOT et via JIT-Compiler a été retirée. C'était expérimental, mais la communauté n'a pas montré un gros engouement pour cette possibilité. Il reste possible d'obtenir la même chose via GraalVM, car AOT et JIT-Compiler se basait sur les travaux autour de GraalVM, mais personnellement j'aurai préféré une fusion des deux plateformes, sait-on jamais, on pourrait voir un nouveau projet du genre à l'avenir.

Pour RMI Activation, l'API était déjà déprécié depuis Java 15, on peut toujours faire du RMI (pas de panic !) mais cette partie de RMI qui était totalement obsolète a été totalement supprimée. On reste dans la logique de réduire l'API Java des API obsolète ou non utilisées pour se concentrer sur ce qui est vraiment important et délivrer plus de valeur.

Petit retour en arrière côté Oracle

Ce n'est pas une nouveauté du JDK en lui-même mais la version Oracle du JDK 17 est accompagné d'un changement au niveau de la licence. En effet la licence change, on peut de nouveau utiliser sans restriction le JDK Oracle pour un usage personnel ou commercial sans souci. Le support des versions LTS sera plus long d'un an sur la version Oracle comparé à la version OpenJDK.

Évidemment il est toujours possible de souscrire à une offre de support pour avoir accès à quelques outils, la version Enterprise de GraalVM et de l'assistance technique.

Conclusion

On est face à une petite mise à jour de part les changements mais c'est une version importante, car il s'agit de la nouvelle version LTS de Java. Java 11 – bien que supporté jusqu'en 2024 – n'est donc plus la version de référence.

Que vous soyez en Java 16 ou en Java 11 sur vos projets, je pense que vous pouvez tenter de monter votre version Java pour au minimum voir si des points critiques sont à prendre en compte sur vos projets.

Sources:

Crédit photo : https://pixabay.com/photos/auto-old-car-car-historic-1087253/