Les fonctionnalités prévues pour le JDK 13 (Java Development Kit), prochaine version du Java standard, incluent désormais les blocs de texte. La réimplémentation de l'ancienne API socket, des améliorations du ramasse-miettes et du partage de données de classe application font aussi parti des objectifs officiels. De plus, les littérales de chaînes brutes, une fonctionnalité liée aux blocs de texte, ont été supprimées tandis qu'un deuxième aperçu des expressions de commutation a été proposé.

Le JDK 13 est prévu pour le 17 septembre 2019, après les étapes dites de Ramp-down et de candidate release qui démarreront respectivement en juin et en août. Voici les fonctionnalités officiellement proposées pour le JDK 13.

L'ajout de blocs de texte dans une phase de prévisualisation

Un bloc de texte est une chaîne de littéraux à plusieurs lignes qui évite d'avoir besoin de la plupart des séquences d'échappement. Un bloc de texte formate automatiquement la chaîne d'une manière prévisible et laisse aux développeurs le contrôle du format. Le projet précise un certain nombre d'objectifs liés à l'ajout de blocs de texte à Java. L'un d’eux est de simplifier l'écriture des programmes Java en facilitant l'expression des littéraux de chaînes couvrant plusieurs lignes de code source tout en évitant les séquences d'échappement dans les cas courants. Un second objectif est d'améliorer la lisibilité des littéraux de chaînes dans les programmes qui indiquent le code écrit dans des langages autres que Java. Un troisième objectif est de supporter la migration à partir des littéraux de chaîne en stipulant que n'importe quelle nouvelle construction peut exprimer le même ensemble de chaînes qu'un littéral de chaîne, interpréter les mêmes séquences d'échappement, et être manipulée comme un littéral de chaîne. Les littéraux de chaîne brutes, une fonctionnalité proposée pour le JDK 13 mais abandonnée en faveur des blocs de texte, traitaient autrement le problème de désignation des chaînes sans échapper aux nouvelles lignes et aux guillemets. Les littéraux de chaîne bruts se concentraient sur le caractère brute des chaînes, mais l'équipe du projet Java pense maintenant que ce choix n’était pas pertinent, parce que si les littéraux de chaîne bruts pouvaient couvrir plusieurs lignes de code source, ils impliquaient aussi un support coûteux des délimiteurs sans échappement. Des littérales de chaines brutes avaient été envisagées pour le JDK 13 mais elles n’ont jamais été officiellement ajoutées à la liste des propositions de fonctionnalités.

Réimplémentation de l'ancienne API socket. Cette réimplementation implique le remplacement de l'implémentation sous-jacente utilisée par net.Socket et java.net.net.ServerSocketAPIs par une implémentation plus simple, plus moderne et facile à déboguer et à maintenir. La nouvelle implémentation doit faciliter le travail avec des threads en mode utilisateur, également connus sous le nom de fibres, qui sont à l'étude dans Project Loom. Les API héritées mentionnées ci-dessus font référence à la version 1.0 du JDK et comprennent un mélange d'anciens codes C et Java réputés fastidieux à déboguer et à maintenir. L’ancienne implémentation pose également d'autres problèmes : il faut une structure de données native pour prendre en charge la clôture asynchrone, à l’origine de problèmes de fiabilité et de portage, et des problèmes de concurrence nécessitant une révision.

Un deuxième aperçu des expressions de commutation a été proposé pour le JDK 13. Il y en avait eu un pour le JDK 12, mais un changement est envisagé : pour obtenir une valeur à partir d'une expression de commutation, le break avec l'instruction de valeur doit être remplacée par une instruction de rendement. Le but est d'étendre le switch pour qu'il puisse être utilisé soit comme instruction, soit comme expression, de sorte que les deux formes puissent soit utiliser la casse traditionnelle ... : labels with fall through (permet à une branche son exécution dans une autre) ou la nouvelle casse... -> labels without fall through, avec une autre nouvelle instruction pour donner une valeur à partir d'une expression switch. Ces changements simplifieront le codage et prépareront l'appariement de modèles.

Amélioration du ZGC (Z Garbage Collector) et plus particulièrement la restitution de mémoire inutilisée au système d'exploitation. Cette proposition est mentionnée comme étant intégrée dans le JDK 13. ZGC, décrit comme un ramasse-miettes évolutif et à faible latence, ne renvoie pas la mémoire inutilisée au système d'exploitation, même si la mémoire n'a pas été utilisée depuis longtemps. Ce comportement n'est pas optimal pour certaines applications et certains environnements, en particulier ceux où l'empreinte mémoire est un problème, comme les conteneurs ou les environnements où une application peut rester inactive pendant longtemps et partager des ressources avec d’autres applications ou en concurrence avec d'autres applications pour l’accès aux ressources.

Extension du partage de données de classe d'application (AppCDS). Cette extension doit permettre l'archivage dynamique des classes à la fin de l'exécution de l'application. Les classes archivées incluraient toutes les classes d'applications et de bibliothèques chargées qui ne sont pas présentes dans l'archive CDS par défaut de la couche de base. Cette proposition, en phase cible, vise à améliorer la convivialité d'AppCDS et à éviter aux utilisateurs d'effectuer des exécutions tests pour créer une liste de classes pour chaque application.

Un outil de packaging en attente d’officialisation

Une autre capacité proposée pour le JDK 13 n'a pas encore été ajoutée à la liste officielle. Il s’agit du développement d'un outil pour le packaging d'applications Java autonomes, appelé jpackage. L'outil serait basé sur l'outil JavaFX javapackager qui supporte les formats d'emballage natifs pour offrir à l'utilisateur une expérience d'installation naturelle. Il permet de spécifier les paramètres de lancement au moment du packaging. L'outil peut être appelé directement par ligne de commande ou par programmation via le ToolProvider. De nombreuses applications doivent être installées sur une plateforme native selon une modalité de « première classe » plutôt que d'être placées sur le chemin de classe ou le chemin de module. Un outil d’emballage peut également combler les lacunes laissées par des technologies comme Java Web Start, supprimée du JDK 11 d'Oracle. L'outil javapackager a été supprimé du JDK 11 en même temps que JavaFX.

Les versions builds bêta du JDK 13 sont téléchargeables sur le site jdk.java.net. Les premières versions bêta du JDK 13 sont disponibles pour Linux, MacOS et Windows.