Évolution de Java en 2024 : Oracle veut étendre le langage avec des projets OpenJDK comme Amber, Leyden, etc.

Évolution de Java en 2024 : Oracle vise à enrichir le langage avec les projets OpenJDK comme Leyden, Panama et Valhalla
pour améliorer la productivité, le temps de démarrage des applications, etc.

Nicolai Parlog, Java Developer Advocate (chargé des relations avec les développeurs Java d'Oracle), a publié il y a quelques jours une vidéo sur les plans de développement du langage Java pour les douze prochains mois. Un certain nombre de projets OpenJDK sont couverts, notamment Amber, Babylon, Leyden, Lilliput, Loom, Panama et Valhalla. Par conséquent, qu'il s'agisse du filtrage ou d'autres améliorations du langage, des interactions avec le code externe, de la mémoire ou des plateformes, l'efficacité de la mémoire, ou encore du temps de démarrage, il existe de nombreux domaines dans lesquels Java s'améliorera en 2024.

Dans sa vidéo, publiée le 18 janvier, Parlog a fait allusion à de nombreuses nouvelles fonctionnalités sur lesquelles l'équipe de développement de Java pourrait travailler en 2024. Cependant, il a averti que la majorité des travaux entrepris au cours d'une année pourraient ne pas être publiés la même année, ce qui signifie que les améliorations seront disponibles en 2025 ou plus tard. Les points mentionnés par Parlog couvrent les projets OpenJDK tels que Babylon, Amber, Leyden, Lilliput, Loom, Panama et Valhalla. Ces projets visent à améliorer Java dans des domaines. Voici ci-dessous en quoi consistent ces projets :

Babylon

Proposé en septembre par Paul Sandoz, architecte chez Oracle, Babylon est un projet qui vise à étendre la portée de Java aux modèles de programmation étrangers grâce à une amélioration de la programmation réflexive en Java, connue sous le nom de réflexion du code. Selon la proposition, cela permettrait l'accès standard, l'analyse et la transformation du code Java sous une forme appropriée. La prise en charge d'un modèle de programmation étranger pourrait alors être plus facilement mise en œuvre sous la forme d'une bibliothèque Java.

https://youtu.be/iL7d-gGrms8

Babylon s'assurerait que la réflexion du code est adaptée à l'objectif en créant un modèle de programmation GPU pour Java qui tire parti de la réflexion sur le code et qui est mis en œuvre sous la forme d'une bibliothèque Java. Afin de réduire le risque de biais, le projet Babylon explore ou encourage l'exploration d'autres modèles de programmation tels que SQL et la programmation différentielle. En expliquant ce que Babylon permettrait de faire, Sandoz a cité l'exemple d'un développeur qui souhaite écrire un noyau GPU en Java et l'exécuter sur un GPU.

Le code du développeur doit être analysé et transformé en un noyau GPU exécutable. Bien qu'une bibliothèque Java puisse le faire, elle nécessite l'accès au code Java sous forme symbolique. Cet accès est actuellement limité à l'utilisation d'API non standard ou à des conventions à différents moments du cycle de vie du programme, c'est-à-dire au moment de la compilation ou de l'exécution. En outre, les formes symboliques disponibles (arbres syntaxiques abstraits ou bytecodes) sont souvent mal adaptées à l'analyse et à la transformation.

L'équipe Babylon prévoit de publier quelques cas d'utilisation dans les semaines à venir, tels que l'autodifférenciation, l'émulation LINQ en C#, et la programmation GPU. L'émulation LINQ C# et la programmation GPU. Cependant, le projet Babylon en est encore à ses débuts, et Parlog ne s'attend donc pas à ce que quelque chose de substantiel en ressorte en 2024.

Amber

Le projet Amber est une initiative des développeurs de Java et d'OpenJDK visant à livrer quelques changements petits, mais essentiels au JDK pour rendre le processus de développement plus agréable. L'objectif du projet Amber est d'explorer et d'incuber de petites fonctionnalités du langage Java orientées vers la productivité qui ont été acceptées comme JEP candidates dans le processus JEP de l'OpenJDK. Ce projet est sponsorisé par le Compiler Group.

La plupart des fonctionnalités du projet Amber font l'objet d'au moins deux cycles de prévisualisation avant de devenir une partie officielle de la plateforme Java. Pour une fonctionnalité donnée, il existe des JEP distincts pour chaque cycle de prévisualisation et pour la normalisation finale. Les fonctionnalités en cours de prévisualisation comprennent des modèles de chaînes de caractères, une méthode principale simplifiée et des déclarations avant this() et super().

Parlog a déclaré que ces fonctionnalités devraient être disponibles cette année. « Je m'attends à ce que ces trois éléments soient finalisés en 2024 », a déclaré Parlog. Des fonctionnalités telles que les types primitifs dans les motifs et avec les expressions sont en cours d'exploration.

Leyden

Leyden vise à améliorer le temps de démarrage des applications Java, le temps d'obtention des performances maximales et l'empreinte des programmes Java. Il introduit une transformation significative de l'optimisation Java en mettant en œuvre une méthode décrite à l'origine comme un "déplacement et une contrainte" du calcul. Au lieu de dépendre uniquement de la compilation du runtime, Leyden déplace certains des processus d'optimisation requis vers des étapes antérieures (comme la compilation Ahead-of-Time), en fonction des besoins spécifiques du programme et de l'environnement d'exécution.

Le principal nouveau composant introduit par Leyden est appelé "condensateurs". Ils peuvent être considérés comme des outils spécialisés qui s'exécutent de manière séquentielle, améliorant ainsi le code de l'application. La procédure commence par une configuration de base de l'application. Au fur et à mesure qu'elle passe par chaque condensateur, des transformations sont mises en œuvre jusqu'à ce que l'étape finale soit atteinte : une version optimisée destinée à un temps d'exécution efficace. Le processus est similaire à l'intergiciel (middleware) dans les frameworks Web comme Express.js pour Node.js.

Dans le domaine du développement Web, les intergiciels interceptent les demandes, les traitent et peuvent même les modifier avant qu'elles n'arrivent à leur destination. Dans le même ordre d'idées, les condensateurs Leyden prennent ApplicationModel (une représentation fixe de l'application) et en génèrent une version améliorée. Cette méthode garantit que le modèle original reste intact, tandis que les optimisations produisent de nouvelles versions améliorées. Le projet Leyden est sponsorisé par les groupes HotSpot et Core Libraries.

Lilliput

L'objectif de ce projet est d'explorer les techniques permettant de réduire la taille des en-têtes des objets Java dans la machine virtuelle Hotspot de 128 bits à 64 bits ou moins, réduisant ainsi l'empreinte mémoire de Java. La réduction de la taille de l'en-tête diminuerait considérablement la pression sur la mémoire, réduisant ainsi l'utilisation globale du CPU et de la mémoire pour toutes les charges de travail Java, qu'il s'agisse d'une grande base de données en mémoire ou d'une petite application conteneurisée.

Une amélioration des performances dans la plupart des charges de travail (sinon toutes) est également attendue. Ce projet est sponsorisé par le HotSpot Group. Les avantages spécifiques cités pour le projet Lilliput sont les suivants :

• réduction de l'utilisation du tas ;
• taux d'allocation d'objets plus élevé ;
• réduction de l'activité de ramassage des ordures ;
• des objets mieux empaquetés.

Loom

Le projet Loom est une initiative de la communauté OpenJDK qui vise à introduire une construction concurrentielle légère dans Java. Selon ces auteurs, le projet Lomm a pour but de réduire considérablement l'effort d'écriture, de maintenance et d'observation des applications concurrentes à haut débit qui utilisent au mieux le matériel disponible. Jusqu'à présent, les prototypes de Loom ont introduit un changement dans la JVM ainsi que dans la bibliothèque Java.

Panama

Le projet Panama est une initiative visant à améliorer et enrichir l'interopérabilité entre la machine virtuelle Java et des API "étrangères" bien définies, c'est-à-dire non Java, qui incluront très probablement des interfaces couramment utilisées dans les bibliothèques C. Selon les auteurs du projet, les bibliothèques non java devraient être facilement accessibles aux développeurs Java. À cette fin, le projet Panama inclura la plupart ou la totalité des composants suivants :

• appel de fonctions natives à partir de la JVM ;
• accès aux données natives à partir de la JVM ou dans le tas de la JVM ;
• nouvelles dispositions de données dans le tas de la JVM ;
• définition de métadonnées natives pour la JVM ;
• outils d'extraction d'API de fichiers d'en-tête (jextract) ;
• API de gestion des bibliothèques natives ;
• interprète orienté natif et "hooks" d'exécution ;
• résolution de classes et de méthodes "hooks" ;
• optimisations JIT orientées natives ;
• interposition d'outils ou de wrappers pour la sécurité ;
• travail exploratoire avec des bibliothèques natives difficiles à intégrer.

Valhalla

Le projet Valhalla est une initiative à long terme au sein de la communauté OpenJDK qui vise à introduire des types de valeurs dans le langage de programmation Java. L'objectif principal du projet est d'améliorer les performances et l'efficacité de la mémoire de Java en fournissant un moyen plus souple et plus efficace de représenter les données. Les types de valeurs s'écartent considérablement de l'approche traditionnelle orientée objet, en offrant un nouveau mécanisme de traitement de certains types de données.

Pour rappel, lorsque Java a été introduit pour la première fois en 1995, il a été décidé que tous les types créés par l'utilisateur seraient des classes. Seule une poignée de types primitifs ont été mis à part. Ils n'ont pas été traités comme des structures de classe basées sur des pointeurs, mais ont été directement mis en correspondance avec les types du système d'exploitation. Les huit types primitifs sont int, byte, short, long, float, double, boolean et char. Il s'avère que ce choix a de grandes implications qui se sont aggravées au fil des ans.

Cette décision de conception apparemment mineure pose des problèmes dans des domaines clés tels que les collections et les génériques. Elle limite également certaines optimisations des performances. Le projet Valhalla, le remaniement du langage Java, vise à corriger ces problèmes. Brian Goetz, chef du projet Valhalla, a déclaré que Valhalla allait "combler le fossé entre les primitives et les objets".

Et vous ?

:fleche: Que pensez-vous des projets OpenJDK susmentionnés ?
:fleche: Lequel de ces projets suscite le plus votre enthousiasme ? Pourquoi ?

Voir aussi

:fleche: L'OpenJDK formule une proposition visant à rendre Java plus facile à apprendre pour les débutants à travers une fonctionnalité du JDK 21 qui est actuellement désactivée par défaut

:fleche: Annonce de CheerpJ 3.0 : un remplacement de la JVM en HTML5 et WebAssembly pour exécuter des applications et des applets Java sur les navigateurs modernes, cette version intégrera un compilateur JIT

:fleche: Malgré OpenJDK, 70% des correctifs et fonctionnalités Java proviennent d'Oracle, selon des statistiques d'Oracle sur les problèmes résolus dans JDK 11 - JDK 20 par organisation