Une proposition OpenJDK appelée Project Babylon envisage d’étendre Java à des modèles de programmation étrangers tels que les modèles d'apprentissage machine, les GPU, SQL et la programmation différentielle. Publié le 6 septembre dans une liste de diffusion openjdk.org par l’architecte d’Oracle Paul Sandoz, cette initiative propose, pour y parvenir, d’améliorer la programmation réflexive dans Java, connue sous le nom code reflection. Selon la proposition, cela offrirait 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 non Java pourrait alors être plus facilement mise en œuvre sous la forme d'une bibliothèque Java. Babylon s'assurerait que le code réflexif est adaptée à l'objectif en créant un modèle de programmation GPU pour Java. Pour réduire les risques de biais, le projet explorerait ou encouragerait l'exploration d'autres modèles de programmation tels que SQL et la programmation différentielle. Le code reflection comporte trois aspects : La modélisation des programmes Java en tant que modèles de code, adaptés à l'accès, à l'analyse et à la transformation ; des améliorations de la réflexion en Java, qui permette l'accès aux modèles de code au moment de la compilation et de l'exécution ; une API pour construire, analyser et transformer les modèles de code.
Un premier test sur un clone de JDK 22
Pour expliquer l’utilité de Babylon, Paul 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. Même si une bibliothèque Java pourrait suffire, elle aurait besoin d’accéder 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. De plus, les formes symboliques disponibles (arbres syntaxiques abstraits ou bytecodes) sont souvent mal adaptées à l'analyse et à la transformation.
Les étapes du projet prévoient une livraison progressive de Babylon, dans une série de propositions d'amélioration du JDK (JEP) qui pourraient s'étendre sur plusieurs versions de fonctionnalités. La réflexion sur le code commencerait par un clone de la version principale du JDK 22, prévue pour mars 2024, et suivrait les versions principales à l'avenir. Pour le modèle de programmation GPU, le projet créerait un référentiel distinct dépendant des fonctionnalités de réflexion sur le code à mesure de leur développement. Pour l’instant, le projet ne prévoit pas d'intégrer le modèle de programmation GPU dans le JDK, mais les travaux sur ce modèle pourraient permettre d'identifier des fonctionnalités et des améliorations du JDK d'utilité générale qui pourraient être prises en compte plus tard.
Commentaire