Ce blogue met l’accent sur le processus de mise à niveau des applications basées sur Gradle de Java 1.8 à Java 17.
La transition de JDK 1.8 à 17 est un aspect important à considérer, car Oracle et de nombreux autres fournisseurs cesseront leur soutien à JDK 1.8 dans le futur. Puisque JDK 1.8 et 17 sont tous deux des versions LTS de Java, l’avantage de l’utilisation d’une version LTS réside dans leur stabilité et la publication fréquente de correctifs de bogues et de mises à jour. Par conséquent, il est conseillé de migrer vers la dernière version bénéficiant d’un support à long terme pour votre application.
De nombreuses nouvelles fonctionnalités ont été introduites dans JDK 17 pour améliorer les performances des applications. En voici quelques-unes :
- Modifications du mécanisme de compilation juste-à-temps
- Amélioration du niveau du langage
- Fonctionnalités liées à la sécurité
Pour atteindre notre objectif de mettre à niveau une application de JDK 1.8 vers JDK 17, il faut suivre les étapes suivantes :
Prendre connaissance des principales fonctionnalités JDK introduites à chaque version :
La meilleure façon de commencer est de consulter le guide de migration et la documentation de publication disponibles sur le site Web officiel du fournisseur du JDK. Cela permet de faire la lumière sur les nouvelles fonctionnalités et les modifications apportées dans la dernière version du JDK. Voici quelques-uns des changements majeurs après JDK 1.8 :
- Amélioration du ramasse-miettes
- Modularité
- Outil shell Java
- Encapsulation renforcée des éléments internes du JDK
- Dépréciation de nombreuses classes et packages Java
Et la liste continue.
Évaluer votre application et documenter les problèmes possibles après la migration :
Une fois les fonctionnalités et changements du JDK compris, il est crucial d’évaluer le code de l’application pour tout problème potentiel de compatibilité après la migration. Dans notre cas, des problèmes sont survenus en raison de versions obsolètes de Gradle et Groovy, qui étaient incompatibles avec JDK 17. La première étape consistait à mettre à niveau Gradle et Groovy au sein de l’application et à ajuster les configurations dans le fichier build.gradle en conséquence.
De plus, toute bibliothèque tierce utilisée dans l’application doit être mise à niveau si elle n’est pas compatible avec JDK 17. Par exemple, la dépendance Spring Boot version 2.3 a des dépendances transitives de CGLIB et ASM. Cependant, CGLIB peut ne pas fonctionner correctement avec la dernière version du JDK, nécessitant une mise à niveau de la dépendance Spring Boot pour garantir la compatibilité avec JDK 17.
Ajouter des dépendances pour les API dépréciées dans les versions de JDK :
La plupart des API ont été supprimées de chaque version du JDK. Par exemple, Java Architecture for XML Binding (java.xml.bind) est supprimé dans JDK 11 et RMI Activation est supprimé dans JDK 17. Ainsi, si la base de code utilise une telle API, alors soit il faut supprimer la dépendance de cette API, soit explorer des dépendances alternatives pour satisfaire aux exigences nécessaires.
Ajouter des arguments de la VM pour accéder aux classes internes du JDK :
La plupart du code applicatif pourrait utiliser des classes du JDK qui ne sont plus publiques. Dans le cadre de l’encapsulation renforcée de JDK, Java a restreint l’accès à ces classes. Mais il existe une solution pour utiliser ces packages :
ajouter l’argument VM --add-opens module/package=target-module
ex. : --add-exports java.base/sun.security.x509=ALL-UNNAMED.
Cependant, il est conseillé de retirer la dépendance à ces packages, car Java finira par restreindre complètement l’accès et la solution ci-dessus ne sera plus utile dans les futures versions du JDK.
Supprimer l’utilisation des paramètres VM dépréciés :
La plupart des paramètres JVM ont été supprimés par JDK, ce qui a causé une erreur à l’exécution pour les applications utilisant de tels paramètres. Pour identifier ces paramètres et les retirer de votre code, par exemple PrintGCDetails.
Réécrire le code qui pourrait appeler des fonctions et classes dépréciées :
Il peut exister des parties de code dans votre application qui invoquent des fonctions dépréciées. Par exemple, le code pourrait utiliser l’API de réflexion comme ci-dessous, ce qui ne fonctionnera plus après la mise à niveau :
ClassLoader callerClassLoader = Reflection.getCallerClass(3).getClassLoader();
Donc, l’utilisateur doit trouver une autre solution ou retirer la dépendance à un tel code.
Bien que le processus ci-dessus puisse paraître laborieux, la migration d’une application existante vers la dernière version sera extrêmement bénéfique pour la performance avec des fonctionnalités avancées.
Lien de référence :
https://www.oracle.com/java/technologies/javase/17-relnote-issues.html
