Java 25 est sorti le 16 septembre et est désormais disponible en télécharrgement chez les principaux distributeurs (Eclipse Temurin par exemple) ainsi qu’en images dockers pour la plupart des systèmes. Voici quelques conseils pour pouvoir migrer.

Le passage de java 21 à java 25 ne devrait pas provoquer de grosse rupture sur les applications de gestion classiques. Les retraits portent sur des éléments déjà dépréciés depuis plusieurs versions ou qui ne sont plus utilisés. La suite du document reprend les principaux changements et un résumé des plus mineurs. Par contre les dépréciations ne sont pas mentionnées.

Pour les lib avec annotations processors (lombok, …) Link to heading

Lombok est un annotation processor : ce qui signifie que la librairie génère du code à la compilation suivant les annotations existantes dans le code compilé. De nombreuses autres librairies de la sorte existent comme Manifold qui permettent de générer du code utile à la compilation à partir de simples annnotations. A partir de java 23, le comportement par défaut de java n’est plus de traiter automatiquement les annotation processors. Ainsi il ne suffit plus d’avoir lombok dans son classpath pour que l’annotation processor soit appelé : il faut spécifier explicitement au compilateur de le faire à l’aide d’une option sur la ligne de commande. La façon de faire recommandée consiste à explicitement placer les librairies d’annotation processor dans le --processor-path (en plus du classpath). Ce qui donne pour un fichier pom.xml dans le cas de lombok :

    <dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <!--Autres dépendances du projet-->
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.14.0</version>
                <configuration>
                    <!--Ajout nécessaire à partir de java 23-->
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>
            <!-- Autres plugins du projet-->
        </plugins>
        <!--éventuelles autres configurations pour le build-->
    </build>

NB : fichier pom.xml reproduit partiellement avec seulement les parties pertinentes

Le Security Manager va être supprimé Link to heading

  • la classe SecurityManager va être supprimée : elle existe encore mais les appels conduisent à des erreurs

  • il faut supprimer :

    • les appels à System#setSecurityManager et System#getSecurityManager
    • les utilisations de la propriété système java.security.manager
    • L’utilisation de la classe javax.security.auth.Subject (pour gérer le informations d’authentification) ne doivent plus s’appuyer sur le security manager mais sur la nouvelle API Java Authentication and Authorization Service (JAAS) :
      • Remplacer Subject::doAs par Subject::callAs
      • Remplacer Subject::getSubject par Subject::current

  • Voir la JEP 486 pour les motivations de la suppression et les alternatives

Des flags de la ligne de commande supprimés Link to heading

Ce sont des flags qui n’ont plus de raison d’être ou sont sans effet mais qui peuvent encore traîner dans certains scripts :

  • -XX:[+-]RegisterFinalizersAtInit
  • -XX:+UseEmptySlotsInSupers
  • -Xnoagent
  • -t
  • -tm
  • -Xfuture
  • -checksource
  • ‘-cs`
  • -noasyncgc

-profile et -p sont retirés de jdeps car les options en question étaient dépréciées

Le module jdk.random est retiré Link to heading

Les packages du module jdk.random ont été déplacés dans java.base

Changements plus annodins Link to heading

On note des changements “plus annodins” car la plupart des applications ne devraient pas être concernées. Au besoin ils sont détaillés dans la vidéo citée en référence (bien lire les liens dans la description de la vidéo) :

  • utilisation interdite de final avec un record pattern
  • utilisation interdite de include comme nom de propriété dans les fichiers de propriétés pour la sécurité
  • Vérification de nullité lors de l’utilisation de la réflexioon dans les contructeurs des classes internes
  • Warning lors de l’utilisation de sun.misc.Unsafe et restrictions sur certaines opérations de JNI et Foreign function memory api
  • Suppressions (éléments déjà dépréciés) :
  • Correction de “bogues” sur l’utilisation des I/O avec Windows :
    • les chemins commençant en \\? sont maintenant acceptés
    • les noms de fichiers et de répertoires finissant par des espaces sont rejettés (comme dans les outils natifs windows)
    • il n’y a plus de tentative de supprimer des fichiers en lecture seule
  • Ne plus utiliser les définitions de locales tirées de JRE/COMPAT (affecter la valeur COMPAT ou bien JRE à la propriété java.locale.providers n’a aucun effet : utiliser CLDR (c’est ce que fait java par défaut avec CLDR version 44

Scanner son code à la recherche d’éléments dépréciés d’API Link to heading

Référence Link to heading