Maintenant que Java 18 est features complete (Rampdown Phase One au jour d’écriture de l’article), c’est le moment de faire le tour des fonctionnalités qu’apporte cette nouvelle version, à nous, les développeurs.

Cet article fait partie d’une suite d’article sur les nouveautés des dernières versions de Java, pour ceux qui voudraient les lire en voici les liens : Java 17, Java 16, Java 15, Java 14, Java 13, Java 12, Java 11, Java 10, et Java 9.

JEP 400: UTF-8 by Default

Avec la JEP 400, le charset par défaut devient UTF-8 pour tous les OS et dans toutes les locales.
Il est possible d’utiliser la variable système file.encoding pour configurer un charset par défaut différent ou de la configurer à COMPAT pour revenir au fonctionnement précédent.

Plus d’informations dans la JEP-400.

JEP 413: Code Snippets in Java API Documentation

Ajout d’un nouveau tag JavaDoc @snippet qui peut être utilisé pour définir un fragment de code. Celui-ci est plus flexible que le tag @code existant, n’a pas besoin d’escaper les caractères spéciaux, et permet même d’inclure des fragments de code depuis un fichier externe.

Exemple de fragment défini au sein de la JavaDoc :

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 *     System.out.println("v: " + v.get());
 * }
 * }
 */

Exemple de fragment défini en dehors de la JavaDoc :

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet file="ShowOptional.java" region="example"}
 */

Ce fragment pointe vers la section example du fichier ShowOptional.java :

public class ShowOptional {
    void show(Optional<String> v) {
        // @start region="example"
        if (v.isPresent()) {
            System.out.println("v: " + v.get());
        }
        // @end
    }
}

Il y a plusieurs options possibles de formatage et d’inclusion des fragments externes; vos fragments deviennent alors exécutables, vous pouvez même les définir dans des tests JUnit par exemple, pour qu’ils soient testés en même temps que le reste de votre code.
Plus d’exemple dans cet article de Gunnar Morling : Executable JavaDoc Code Snippets.

Plus d’informations dans la JEP-413.

JEP 408: Simple Web Server

Cette JEP ajoute à la distribution OpenJDK un serveur web minimaliste qui permet de servir des fichiers statiques depuis un répertoire via un outil ligne de commande : jwebserver.

Par défaut, ce serveur web s’expose sur localhost (configurable via -b), utilise le port 80 (configurable via -p), et sert des fichiers statiques dans le répertoire courant (configurable via -d).
Chaque accès à celui-ci sera logué dans la sortie standard.

En plus d’un outil ligne de commande, vous pouvez utiliser la classe SimpleFileServer pour instancier un serveur web via son API Java.

var server = SimpleFileServer.createFileServer(new InetSocketAddress(8080), 
        Path.of("/some/path"), OutputLevel.VERBOSE);
server.start()

Plus d’exemples d’utilisation de l’API Java dans l’article Working with the Simple Web Server de Julia Boes.

Plus d’informations dans la JEP-408.

JEP 421: Deprecate Finalization for Removal

La finalisation est le mécanisme par lequel il est possible d’effectuer automatiquement des actions juste avant la destruction d’un objet. Ce mécanisme a un ensemble de problème, entre autres, il délaie le moment où ces actions sont effectuées au passage du garbage collector et une méthode finalize() mal codée peut faire revivre la référence à détruire.

Depuis java 9 et la dépréciation de la méthode finalize() de la classe Object, il est déconseillé d’utiliser la finalisation et, pour libérer des ressources liées à une classe, il est conseillé d’utiliser d’autres mécanismes tel que le try-with-resource ou la nouvelle api Cleaner.

La JEP 421 va un pas plus loin dans la suppression de la finalisation en dépréciant pour suppression le mécanisme de finalisation lui-même. Vous pouvez dès à présent tester votre code sans finalisation via l’option JVM --finalization=disabled.

Plus d’informations dans la JEP-421.

Des changements internes, de la performance, et de la sécurité

Chaque nouvelle version du JDK apporte ses optimisations de performances (entre autres GC et méthodes intrisics), et de sécurité. Celle-ci ne fait pas défaut, et on peut citer entre autres des optimisations dans G1 GC (amélioration de la gestion des remember set, voir JDK-8017163) et Parallel GC, ainsi que dans la gestion des encoding des chaînes de caractères.
Un autre ajout notable est le support de la dé-duplication de String pour les garbage collector Serial GC, Parallel GC et ZGC.

On peut aussi noter deux JEP importantes sur des mécanismes internes de la JVM :

• JEP 418 : Internet-Address Resolution SPI : possibilité de changer l’implémentation par défaut de résolution des adresses internet.
• JEP 416 : Reimplement Core Reflection with Method Handles : précédemment il y avait trois implémentations permettant de faire des appels de méthode dynamiquement : VM native method (interne), dynamic bytecode et Unsafe (utilisé par java.lang.reflect), et pour finir les method handles (java.lang.invoke). L’API de reflection (java.lang.reflect) a été réécrite pour utiliser l’API MethodHandle pour en supprimer une.

D’autres changements en terme de sécurité ont été implémenté, vous pouvez lire cet article de Sean Mullan sur le sujet : JDK 18 Security Enhancements.

Les fonctionnalités qui restent en preview

Les fonctionnalités suivantes restent en preview (ou en incubator module).

Pour les détails sur celles-ci, vous pouvez vous référer à mes articles précédents.

• JEP-417 – Vector API : troisième incubation de la fonctionnalité.
• JEP-419 – Foreign Function & Memory API : second incubator pour ces deux fonctionnalités rassemblées dans une même JEP.
• JEP-420 – Pattern Matching for switch : seconde preview avec quelques améliorations.

Divers

Divers ajouts au JDK :

• Duration.isPositive()
• Math et StrictMath ont vu l’ajout de nombreuses nouvelles méthodes : ceilDiv, ceilDivExact, ceilMod, divideExact, floorDivExact et unsignedMultiplyHigh

La totalité des nouvelles API du JDK 18 peuvent être trouvées dans The Java Version Almanac – New APIs in Java 18.

Conclusion

Cette nouvelle version de Java n’apporte pas beaucoup de nouveautés, mais fait avancer le projet Panama (Vector API, Foreign Function & Memory API). On espère pour Java 19 avoir les premières JEP des projets Loom (lightweight thread) et Valhalla (value/inline/primitive classes) qui sont en cours d’écriture.

Il faut quand même noter la dépréciation de la finalisation pour suppression, même si sa suppression n’est pas pour tout de suite, c’est quand même un signe fort dans cette direction.