Le Java Development Kit (JDK) 13, la prochaine version de Java standard, a atteint la deuxième étape de la phase de « pré-lancement », ce qui signifie que toutes les nouvelles fonctionnalités ont été verrouillées. L'outil jpackage pour le packaging d'applications Java autonomes, capacité proposée pour le JDK 13, mais jamais ajoutée à la liste officielle, n'est plus à l'étude pour le JDK 13, attendu pour le 17 septembre 2019. Une première « release candidate » devrait être livrée le 8 août. 

En attendant, voici les fonctionnalités officiellement prévues pour le JDK 13 :

L'ajout de blocs de texte dans la phase de prévisualisation. Un bloc de texte est une chaîne de caractères déployée sur plusieurs lignes qui permet d’éviter la plupart des séquences d'échappement. Un bloc de texte formate automatiquement la chaîne de caractères de manière prévisible et laisse aux développeurs le contrôle du format. Le projet relatif à l'ajout de blocs de texte à Java mentionnait plusieurs objectifs. L'un d’eux était de simplifier l'écriture des programmes Java en facilitant l'expression de chaînes de caractères couvrant plusieurs lignes de code source tout en évitant les séquences d'échappement dans les cas courants. Un deuxième objectif était d'améliorer la lisibilité des chaînes de caractères dans les programmes qui révélaient le code écrit dans des langages autres que le Java. Un troisième but était de supporter la migration à partir des littéraux de chaînes en stipulant que n'importe quelle nouvelle construction pouvait exprimer le même ensemble de chaînes qu'une chaîne littérale, interpréter les mêmes séquences d'échappement, et être manipulée comme une chaîne littérale. Les littéraux de chaînes brutes, fonctionnalité proposée pour le JDK 13 mais abandonnée en faveur des blocs de texte, adoptaient une approche différente du problème de désignation des chaînes de caractères sans échapper aux nouvelles lignes et aux guillemets. Les littéraux de chaînes brutes se concentraient sur l’aspect « brut » des chaînes, mais l'équipe du projet Java pense désormais que cette approche n’était pas pertinente, parce que si les littéraux de chaînes brutes pouvaient couvrir plusieurs lignes de code source, ils demandaient des efforts coûteux pour supporter des délimiteurs non échappés. Le projet d’ajout des littéraux de chaînes brutes au JDK 13 avait été formalisé, mais jamais ajouté à la liste des fonctionnalités officiellement proposées. 

Réimplémentation de l'ancienne API socket. elle-ci implique le remplacement potentiel de l'implémentation sous-jacente utilisée par les API net.Socket et java.net.net.ServerSocket par une implémentation plus simple, plus moderne et facile à déboguer et à maintenir. L’objectif de la nouvelle implémentation est de simplifier le travail avec les threads en mode utilisateur, également connus sous le nom de fibres, à l'étude dans Project Loom. Les API héritées susmentionnées remontent à la version 1.0 du JDK et mélangent d'anciens codes C et Java réputés pénibles à déboguer et à maintenir. L'implémentation héritée est également à la source d'autres difficultés : une structure de données native pour prendre en charge la clôture asynchrone, provoquant des problèmes de fiabilité et de portage, et des problèmes de concurrence nécessitant une révision.

Un second 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 prévu : pour obtenir une valeur à partir d'une expression de commutation, la rupture avec l'instruction de valeur doit être remplacée par une instruction de rendement. Le but est d'étendre la commutation pour permettre son utilisation 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», impliquant une nouvelle instruction pour donner une valeur à partir d'une expression de commutation. Ces changements simplifieront le codage et prépareront l'appariement de modèles.

Amélioration du ramasse-miettes ZGC (Z Garbage Collector), afin de restituer la mémoire inutilisée au système d'exploitation. Cette proposition est dite intégrée dans le JDK 13. Actuellement, le ZGC, présenté comme un ramasse-miettes évolutif et à faible latence, ne restitue pas la mémoire inutilisée au système d'exploitation, même si cette mémoire reste inutilisée pendant longtemps. Ce comportement n'est pas optimal pour certaines applications et certains environnements, en particulier ceux où l'empreinte mémoire est problématique, comme les conteneurs ou les environnements où une application peut rester inactive pendant longtemps et partager ou être en concurrence avec d'autres applications pour les ressources.

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

Dans la phase de pré-lancement actuelle, les bogues de priorité 1 à 3 seront corrigés tandis que les bogues de priorité 4 et de priorité 5 seront abandonnés. Quelques bogues de priorité 1 et de priorité 2 peuvent être reportés avec approbation. Cette phase sera suivie par une seconde phase de pré-lancement prévue le 18 juillet et par la livraison d’une première release candidate, le 8 août. Les versions builds 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.