Quelles sont les nouveautés de Java 17 ?

La version Long-Term-Support (LTS) du langage Java et de la plateforme d’exécution Java 17 a été lancée le 14 septembre 2021. Découvrez les nouveautés de Java 17 et l’opportunité d’une mise à jour.

De nombreuses applications utilisent d’anciennes versions de Java, y compris les versions LTS antérieures de Java : Java 11 et Java 8.

Pourquoi les entreprises devraient-elles passer à la version la plus récente de Java ? La mise à niveau vers Java 17 nécessite un effort, principalement pour tirer le meilleur parti des nouvelles caractéristiques et fonctions de la JVM.

De nombreuses entreprises utilisent Docker et les images Docker pour passer facilement à Java 17 avec un minimum d’efforts et de temps. Les développeurs peuvent définir leur pipeline d’intégration/déploiement continu (CI/CD) et tout exécuter dans des images Docker. Cela n’aura pas d’impact sur les autres équipes qui utilisent des versions antérieures de Java, car elles peuvent utiliser les anciennes images Docker.

Caractéristiques de JAVA 17

prise en charge de macOS et AArch64

L’une des caractéristiques essentielles de la JVM ajoutée à cette version est l’amélioration de la prise en charge de macOS sur l’architecture AArch64 à l’aide de la JEP 391. Cela permettra de prendre en charge la dernière série de processeurs (M1) qu’Apple a mis sur le marché avec ses ordinateurs au cours de l’année dernière.

Ce n’est pas nécessairement un gros problème pour les utilisateurs de ces plateformes puisque certains fournisseurs ont lancé des versions du JDK qui prennent en charge cette architecture et retournent même la prise en charge à partir de Java 8. Toutefois, le sceau d’approbation officiel est essentiel pour garantir la maintenance et le soutien futurs de la plateforme. En comparaison, la prise en charge de la plate-forme Linux/AArch64 a été ajoutée à Java 9 et celle de Windows/AArch64 à Java 16.

Classes scellées

Les classes scellées sont une fonctionnalité introduite dans Java 17. Cette fonctionnalité a terminé sa phase d’essai et est devenue une plate-forme et un langage officiels dans Java 17. Elle permet à un développeur de spécifier les sous-types autorisés qu’un type peut avoir et d’empêcher d’autres personnes de l’étendre ou de l’implémenter d’une manière qui n’est pas prévue.

Les classes scellées permettent également au compilateur de générer des erreurs au moment de la compilation lorsque vous tentez de convertir un type non scellé en un sous-type non autorisé. Java 17 apporte également un nouveau pipeline de rendu pour les applications AWT/Swing qui s’exécutent sur macOS en utilisant l’API Apple Metal au lieu d’OpenGL. L’API et les fonctions de génération de nombres aléatoires ont été améliorées.

Changements, suppressions et limitations dans Java 17

Java 17 apporte également plusieurs changements, suppressions et nouvelles limitations.

Encapsulation des éléments internes du JDK

L’un des changements est la fin du processus d’encapsulation des éléments internes du JDK. La première fois que ce processus a été introduit, c’était dans Java 9, et il donnait des avertissements pendant l’exécution lorsqu’un utilisateur tentait d’utiliser la réflexion ou quelque chose de similaire pour contourner les restrictions habituelles sur l’utilisation des API internes. Des arguments de ligne de commande ont également été ajoutés pour réguler ce comportement.

À partir de Java 9, diverses API ont été créées pour offrir un moyen uniforme d’effectuer les tâches les plus courantes ; les utilisateurs se servaient de ces API en interne. Avec Java 16, la valeur par défaut est passée d’un avertissement à la désactivation de l’accès et au lancement d’une exception. Cependant, il utilise l’argument de ligne de commande pour modifier le comportement.

Avec Java 17, l’argument de la ligne de commande est éliminé et il est possible de désactiver cette restriction. Cela signifie que tout accès non autorisé à ces API internes est désormais protégé.

Sémantique de virgule flottante toujours stricte

Une autre “suppression” peut être décrite comme la réintroduction de la sémantique Always-Strict Floating Point. Java 1.2 a introduit des modifications à la sémantique de virgule flottante par défaut dans Java qui permet à la JVM d’échanger une petite quantité de précision dans les calculs de virgule flottante afin d’améliorer les performances. Dans les classes et les méthodes où la sémantique stricte doit être utilisée, un mot-clé strictfp a été ajouté. Depuis lors, divers types de jeux d’instructions ont été introduits dans les CPU, ce qui permet d’utiliser la sémantique stricte de la virgule flottante sans coût inutile. La nécessité d’implémenter une sémantique par défaut ou stricte a été éliminée.

Java 17 supprime l’ancienne sémantique par défaut et toutes les opérations en virgule flottante sont exécutées de manière stricte. Le terme strictfp esttoujours présent. Cependant, il n’a aucun effet et provoque un avertissement au moment de la compilation.

Compilation anticipée (AOT)

Java 9 a introduit la compilation en avance sur le temps (AOT) en tant que fonctionnalité expérimentale qui utilise le compilateur Graal, et un code JIT a été écrit en utilisant Java. Java 10 a rendu le compilateur Graal utilisable comme compilateur JIT dans OpenJDK en incorporant l’interface JVMCI. Depuis sa sortie, le compilateur Graal s’est considérablement amélioré. Le compilateur Graal a connu d’énormes progrès et possède sa JVM sous le nom de GraalVM.

Activation RMI

L’activation RMI a été supprimée dans le JEP 407 à la suite de sa suppression dans Java 8 et a finalement été dépréciée et marquée comme une exigence de suppression dans Java 15. L’activation RMI fournissait une méthode pour activer les ressources à la demande des objets distribués à l’aide de RMI. Cependant, elle n’a été que très peu utilisée et une meilleure alternative est disponible aujourd’hui. Le reste de la RMI n’est pas affecté par l’élimination de la partie Activation.

Suppression de l’API Applet

L’API Applet a finalement été désignée pour être supprimée par la JEP 398, initialement supprimée dans Java 9. L’API Applet permettait d’intégrer des contrôles Java AWT/Swing dans une page web au sein d’un navigateur. Cependant, aucun navigateur moderne ne peut prendre en charge cette API, ce qui signifie que les applets sont pratiquement inaccessibles depuis une dizaine d’années.

Gestionnaire de sécurité

La dépréciation la plus importante concerne le gestionnaire de sécurité ( JEP 411). Le gestionnaire de sécurité est utilisé depuis Java 1.0. Il a été conçu pour restreindre ce que Java pouvait faire localement sur la machine, par exemple en limitant l’accès aux réseaux, aux fichiers et à d’autres ressources réseau. Il tente également de mettre en bac à sable le code qui n’est pas fiable en bloquant la réflexion et des API spécifiques.

La fin du gestionnaire de sécurité a commencé avec Java 12. Un argument de ligne de commande a été ajouté pour bloquer l’utilisation du gestionnaire de sécurité au moment de l’exécution. Le changement effectué dans Java 17 signifie qu’un avertissement d’exécution sera généré dans la JVM lorsque l’on essaiera de définir un gestionnaire de sécurité, que ce soit à partir de la ligne de commande ou dynamiquement à l’exécution.

Caractéristiques de l’incubateur et de l’aperçu

Beaucoup se sont demandés si Java 17 aurait des fonctionnalités de prévisualisation et d’incubation, étant donné que Java 17 a été promu comme une version supportée à long terme. Java 17 dispose de deux modules incubateurs et d’une fonction de prévisualisation !

API vectorielle

Vector API ( JEP 414) est actuellement dans sa deuxième phase d’incubation. L’API permet aux développeurs de définir des calculs vectoriels que le compilateur JIT convertira ensuite en instructions vectorielles appropriées supportées par l’architecture CPU sur laquelle la JVM tourne (par exemple, en utilisant celles des jeux d’instructions SSE ou AVX).

Auparavant, les développeurs devaient utiliser des fonctions scalaires ou créer des bibliothèques natives spécifiques à la plate-forme. L’implémentation de l’API vectorielle dans Java fournit également un mécanisme de repli transparent qui était compliqué dans les versions précédentes.

La normalisation de l’API vectorielle permet aux classes du JDK de l’utiliser. Les méthodes Java Arrays mismatch() pourraient être modifiées pour être exécutées sur Java à la place, éliminant ainsi la nécessité de maintenir et d’écrire de multiples implémentations spécifiques aux plates-formes au sein de la JVM.

Fonction étrangère et API mémoire

Une autre caractéristique de l’incubateur est l’API pour les fonctions et mémoires étrangères ( JEP 412). Il s’agit d’une évolution et d’une fusion de deux autres modules incubateurs de Java 16, à savoir l’API de liaison étrangère ( JEP 389) et l’API de mémoire étrangère ( JEP 393). Ces deux modules permettent d’accéder à la mémoire et au code natifs en utilisant une programmation statiquement typée écrite en Java.

Correspondance de motifs pour Switch

La dernière caractéristique de l’aperçu du langage inclus dans Java 17 est l’inclusion du Pattern Matching for Switch ( JEP 406). Cette fonctionnalité du langage étend les expressions et les instructions de commutation en fonction du type, de manière similaire à la syntaxe utilisée par le biais du Pattern Matching(JEP 394), qui est devenu standard avec Java 16.

Auparavant, si vous souhaitiez effectuer différentes actions en fonction de la nature dynamique d’un objet, vous deviez construire une chaîne if-else à l’aide d’une instance de contrôle telle que :

String type(Object o) {
  if (o instanceof List) {
    return "Une liste de choses" ;
  }
  else if (o instanceof Map) {
    return "Une carte ! Elle possède des clés et des valeurs" ;
  }
  else if (o instanceof String) {
    return "C'est une chaîne de caractères" ;
  }
  else {
    return "Ceci est autre chose" ;
  }
}

En combinant l’expression du commutateur et la nouvelle fonction de recherche de motifs pour les commutateurs, le processus peut être réduit à quelque chose de similaire :

String type(Object o) {
  return switch (o) {
    case List l -> "Une liste de choses." ;
    case Map m -> "Une carte ! Elle possède des clés et des valeurs" ;
    case String s -> "Ceci est une chaîne de caractères" ;
    default -> "Ceci est quelque chose d'autre" ;
  } ;
}

Comme vous l’avez peut-être remarqué, une variable est déclarée dans le processus de vérification. Comme pour les autres variables de Pattern, la correspondance avec instance indique que cet objet a fait l’objet d’une vérification de type et d’un cast et qu’il est disponible à partir de la variable dans sa zone courante.

La fonction de prévisualisation est une autre étape vers la mise en correspondance des motifs. La prochaine étape consistera à inclure la possibilité de déconstruire les tableaux et les enregistrements.

Devriez-vous passer à Java 17 ?

Oui, vous devez constamment passer à la version la plus récente, mais pas dès le premier jour. Les logiciels et les bibliothèques que vous utilisez n’ont peut-être pas été mis à jour pour assurer la compatibilité avec Java 17, de sorte que vous devrez peut-être attendre un certain temps avant que cela ne soit fait.

Si vous êtes coincé avec une version LTS de Java comme Java 8 ou Java 11, il existe de nombreuses options dans le langage et dans la JVM elle-même qui nécessitent une mise à jour vers Java 17. Comme il s’agit d’une version de maintenance à long terme, il y a de fortes chances que votre environnement de production soit également mis à jour vers Java 17.

Si vous commencez un projet entièrement nouveau, ou si vous êtes en train de préparer votre projet pour Java 17, le passage à Java 17 le plus tôt possible est probablement le choix le plus efficace, car il réduit les coûts de migration. Cela permet également aux développeurs travaillant sur le projet d’utiliser toutes les dernières fonctionnalités et le côté opérationnel.

Vous pouvez profiter des nombreuses améliorations apportées au cours des dernières années, telles que la prise en charge améliorée des conteneurs fonctionnant sous Java, ainsi que les nouvelles implémentations de garbage collector à faible latence.