La livraison du JDK 14 n'est pas prévue avant le 17 mars 2020 selon le calendrier de sortie semestriel de Java. Cela n'empêche pas de voir arriver au fil des mois plusieurs nouvelles fonctionnalités, dont les plus récentes viennent d'être proposées. 

- JFR Event Streaming qui fournit une API pour la consommation continue des données JFR des applications en cours et hors processus. JFR est un outil de collecte de données de profilage et de diagnostic sur une application Java en cours d'exécution. La proposition de diffusion des événements en continu enregistre le même ensemble d'événements que dans le cas d’une diffusion sans streaming, avec un temps inférieur à un pour cent si possible. La diffusion d'événements en continu doit coexister avec les enregistrements non diffusés en continu, qu'ils soient sur disque ou en mémoire. Cette proposition est motivée par le fait que la VM HotSpot émet plus de 500 points de données en utilisant JFR, la plupart d'entre eux n'étant disponibles qu'en analysant les fichiers logs. Actuellement, un utilisateur doit lancer un enregistrement, l'arrêter, vider le contenu sur le disque, puis analyser le fichier d'enregistrement. Cela fonctionne bien pour le profilage d'application, mais pas à des fins de surveillance. Comme exemple d'utilisation de la surveillance, on peut citer le cas d’un tableau de bord affichant les mises à jour dynamiques des données. La création d'un enregistrement crée une surcharge, puisqu’il faut copier des données du référentiel depuis le disque dans un fichier d'enregistrement séparé. S’il était possible de lire les données enregistrées à partir du référentiel de disque sans créer un nouveau fichier d'enregistrement, on éviterait une grande partie de cette surcharge.

- L'amélioration prévue de NullPointerExceptions. Les auteurs de la proposition voudraient délivrer des informations utiles aux développeurs et aux équipes de support sur l’interruption prématurée d'un programme et améliorer la compréhension du programme en associant plus clairement une exception dynamique au code statique du programme. L’un des objectifs est de clarifier le sujet des NullPointerExceptions et de rassurer les développeurs.

- Les tampons d'octets mappés non-volatils (NVM) ajouteraient de nouveaux modes de mappage de fichiers spécifiques au JDK qui permettent d'utiliser l'API FileChannel pour créer des instances MappedByteBuffer qui font référence à la mémoire non-volatile (NVM). La NVM permet aux programmeurs de construire et de mettre à jour l'état du programme à travers les exécutions de programme sans risquer des coûts importants de copie ou de traduction habituellement requis par les opérations d'entrée et de sortie. Cet aspect est particulièrement important pour les programmes transactionnels. Donc, l'objectif principal de cette proposition d'amélioration du JDK est de s'assurer que les clients peuvent accéder et mettre à jour le NVM d'un programme Java de manière cohérente et efficace. Un autre objectif plus secondaire est d'implémenter ce comportement de validation à l'aide d'une API restreinte, interne au JDK, définie dans la classe Unsafe, afin qu'elle puisse être réutilisée par des classes autres que MappedByteBuffer qui peuvent avoir besoin de valider dans NVM. Un autre objectif est de permettre aux tampons mappés sur NVM d'être suivis par les API existantes pour la surveillance et la gestion. Les plates-formes OS/CPU cibles incluent Linux/x64 et Linux/AArch64.

- Les expressions switch pour simplifier le codage en étendant le commutateur pour qu'il puisse être utilisé comme une instruction ou une expression. Les expressions switch sont censées être une fonctionnalité permanente du JDK 14. Des preview de la fonctionnalité avaient été intégrées dans les JDK 12 et 13. Les expressions switch préparent également à l’usage du filtrage de motifs dans le commutateur, ce qui permettra aux développeurs d'extraire conditionnellement les composants des objets de manière plus concise et plus sûre.

- L'allocation de mémoire compatible NUMA pour le ramasse-miette G1 : elle est destinée à améliorer les performances du G1 sur les grosses machines. Au passage, on remarque la suppression du ramasse-miette Concurrent Mark Sweep (CMS), par ailleurs prévue et devenu inutile CMS ayant été supplanté par ZGC (Z Garbage Collector) et Shenandoah.

- Le Portage de ZGC sur MacOS et Windows. Jusque-là, il n’était supporté que sous Linux.

- La suppression des outils pack200 et unpack200 et de l'API Pack200 dans le paquet java.util.jar. Tous ces outils été dépréciés dans Java SE 11, avec l'intention de les supprimer plus tard. Pack200 est un outil de compression et de décompression des archives JAR.

Parmi les fonctionnalités officiellement adoptées pour le JDK 14, on trouve également  :

- Une fonction d’enregistrement qui permettrait de disposer d’une syntaxe compacte pour déclarer les classes de « Holder » transparents de données peu immuables. La proposition vise à faciliter et rendre plus concise la déclaration des agrégats de données nominaux peu immuables, bien tabulés et nominaux.

- Un outil de packaging, en phase de développement en incubateur, pour le packaging d'applications Java autonomes. L'outil serait basé sur JavaFX javapackager. Un tel outil avait été inclus dans Java, mais, supprimé du JDK 11 lors de la suppression de JavaFX.

- L'amélioration du langage par filtrage de motif pour l'instance de l'opérateur. Une fonction de prévisualisation pourrait être incluse dans le JDK 14. Le filtrage de motif permet d'exprimer de manière plus concise et plus sûre une logique commune dans un programme, principalement l'extraction conditionnelle de composants dans les objets.

- Une seconde preview des blocs de texte. Cette chaîne de caractères multi-lignes évite la plupart des séquences d'échappement et formate automatiquement la chaîne de caractères de manière prévisible. Les blocs de texte permettraient au développeur d’avoir à tout moment un contrôle sur le format, simplifieraient l'écriture des programmes Java et amélioreraient la lisibilité des chaînes de caractères. Les blocs de texte ont été livrés en preview dans le JDK 13. L'itération pour le JDK 14 ajouterait deux nouvelles séquences d'échappement.

- La dépréciation de la combinaison des algorithmes des ramasse-miettes Parallel Scavenge et Serial Old. Les responsables du développement Java pensent que cette combinaison est très peu utilisée, mais qu’elle nécessite beaucoup de maintenance.