JEP 407 et JEP 410, les fonctionnalités retirées du JDK 17

Contexte

Le JDK évolue pour s’adapter au développement actuel. Cette évolution comprend aussi le retrait de fonctionnalités qui ne sont plus utilisées. En effet, les besoins évoluent selon les architectures utilisées.

L’exemple de la première JEP est significatif par rapport à l’usage du protocole HTTP pour traiter la distribution au lieu d’autres protocoles existants : CORBA, RMI

JEP 407 Remove RMI Activation

astuce Les mécanismes de RMI ne changent pas. Le retrait concerne seulement l’activation RMI.

avertissement Cela n’est pas à confondre avec JavaBean Activation Framework (JAF) de Java EE, qui a été renommée Jakarta Activation depuis la reprise par la fondation Eclipse. Cela ne concerne pas le même sujet et il n’y a aucun impact vis à vis de ce retrait.

Reprenons les bases.

RMI est l’acronyme pour Remote Method Invocation. C’est le moyen en Java de pouvoir appeler une méthode d’un objet distant. C’est à dire que l’instance se trouve sur la même JVM, sur une autre JVM du même ordinateur ou sur une autre JVM d’un autre ordinateur. Cela est transparent pour l’appelant.

Sans rentrer dans le détail (ce n’est pas le but de cet article), voici le principe de fonctionnement de RMI :

RMI

Ce qui veut dire que les serveurs doivent s’enregistrer auprès de l’annuaire.

Et c’est là qu’intervient l’activation RMI. C’est le moyen pour pouvoir activer les objets seulement à la demande. Pour cela, nous avons :

  • Une classe java abstraite java.rmi.activation.Activatable

  • Un utilitaire rmid

Pour plus d’information, je vous laisse lire le sujet d’activation dans les specifications RMI du JDK 11

Un peu d’histoire

Il faut savoir que cette JEP fait suite à la JEP 385 : Deprecate RMI Activation for Removal inclus dans le JDK 15 (septembre dernier).

Suite à l’annonce de la dépréciation (pour suppression) de cette fonctionnalité, il n’y a pas eu de retour à ce sujet. Cela n’est pas une preuve en soit mais une bonne indication.

Pour les systèmes qui l’utilisent, la solution sera de rester sur une ancienne version du JDK ayant un support étendu. Laissant le temps de faire évoluer le système.

Et maintenant ?

Le retrait concerne :

  • Le package java.rmi.activation,

  • Le code d’implémentations,

  • Les tests de non-régression,

  • La spécification RMI dont le volet activation sera supprimé,

  • Le daemon rmid.

JEP 410 Remove the Experimental AOT and JIT Compiler

Un peu d’histoire

Cette JEP est moins problématique car cela correspond à supprimer des fonctionnalités expérimentales du JDK (donc moins d’utilisateurs impactés) :

Le JIT (Just-In-Time) a besoin que la JVM tourne pour commencer les optimisations du code appelé fréquemment (compilateur à la volée). C’est la fameuse phase de "warm-up" de la JVM.

L’AOT consiste à réaliser la compilation native au lieu du code intermédiaire. Ainsi, les performances sont optimales dès le début.

Le compilateur JIT basé en Java (appelé Graal) permet de pouvoir écrire le compilateur JIT en Java et non en C++. Et oui, du code Java qui optimise du code Java. Plus sérieusement, cela permet d’améliorer la maintenabilité du code.

Ces expérimentations ont été à l’origine de la solution GraalVM.

Et maintenant ?

L’effort de maintenir ces solutions est important, donc il a été décidé de les retirer. Le projet Metropolis passe en mode veille.

Le retrait concerne principalement trois modules:

  • jdk.aot - l’outil jaotc,

  • jdk.internal.vm.compiler - le compilateur Graal,

  • jdk.internal.vm.compiler.management - MBeans de Graal.

Il est intéressant de noter que cela n’impacte pas le package jdk.internal.vm.ci. Ce module a été introduit dans le JDK 9 avec la JEP 243 : Java-Level JVM Compiler Interface.

C’est l’API Java qui permet d’avoir des interfaces pour un compilateur en Java (connu aussi sous le nom de JVMCI). Donc même si le compilateur graal n’existera plus, rien n’empêche d’en avoir un nouveau.

La suite

L’équipe est content du travail fourni car cela a permit d’avoir une bonne expérience sur le travail de l’AOT. Cela conforte aussi la direction de solution "Java-on-Java".

Cela sera utile dans la mise en oeuvre du projet leyden.

Les développeurs utilisant le compilateur graal doit se tourner vers la solution GraalVM.