L’idée en cours dans la communauté OpenJDK est de doter Java d'une API qui permettrait de sauvegarder l'état, et d'accélérer ainsi les temps de démarrage. Plus exactement, c’est Anton Kozlov, ingénieur logiciel senior chez l’éditeur Java Azul, qui est à l’origine de la proposition au sein d’un groupe de discussion. Son projet CRaC (Coordinated Restore at Checkpoint) consisterait à développer une API Java de coordination entre une application et le runtime afin de sauvegarder et restaurer son état.

Selon cette proposition, le runtime Java prendrait en charge plusieurs méthodes de sauvegarde de l'état : soit à partir d’un snapshot de la machine virtuelle, soit à partir d’un snapshot du conteneur, soit en s’appuyant sur le projet Linux CRIU (Checkpoint/Restore In Userspace), plus d’autres méthodes. Selon la proposition, les applications Java peuvent éviter les longs démarrages et mises en route en sauvegardant l'état du runtime Java. L'état sauvegardé serait utilisé pour démarrer rapidement les instances.

Des défis à relever

Mais il y a également des défis. En premier lieu, l'environnement d'exécution peut changer après que l'état a été sauvegardé. De plus, si plusieurs instances sont lancées simultanément à partir de l'état sauvegardé, elles devraient être traitées de façon unique et leurs exécutions devraient diverger à un moment donné. La proposition indique que la manière pratique de résoudre ces problèmes est de faire en sorte que les applications Java sachent quand l'état est sauvegardé et restauré. Une application sera alors capable de gérer les changements d'environnement. En outre, l'application sera en mesure d'obtenir l'unicité de l'environnement. La proposition prévoit la conception d'une API suffisamment générale pour tout mécanisme sous-jacent.

De plus, des contrôles de sécurité seront effectués dans l'API et le runtime afin d'empêcher la sauvegarde de l'état si celui-ci ne peut pas être restauré ou fonctionner correctement après la restauration. Il est probable que l'API soit développée dans le cadre du processus JEP (JDK Enhancement Proposal) et intégrée à Java standard, mais aucune version spécifique de Java n'a encore été ciblée pour l'API. L'ensemble des fonctionnalités de la prochaine version de Java, JDK 17, prévue pour septembre, a déjà été gelé.

Des synergies avec Leyden et une librairie compatible

Un commentaire sur la proposition suggère de synchroniser ce travail avec une proposition similaire en cours d’élaboration chez Red Hat. Des synergies possibles avec le projet Leyden, visant à résoudre les problèmes de Java, ont également été mentionnées.

Pour faciliter l'adoption de l'API, la proposition prévoit de mettre à disposition une librairie de compatibilité org.crac. Celle-ci permettrait d'utiliser l'API CRaC avant qu'elle n'apparaisse dans le JDK principal. En cas d'exécution sur une version du JDK qui ne prend pas en charge le CRaC ou l'API, la couche API org.crac agirait comme une couche « no-op » inactive, mais si l'exécution est réalisée sur une version du JDK qui possède des capacités CRaC, la fonctionnalité serait activée et utilisable via des API org.crac, sans qu'aucune modification ne soit nécessaire au code utilisant l'API. Ainsi, la couche API org.crac permettrait aux adoptants de commencer à coder pour les API CRaC sans qu’ils soient obligés de construire des versions distinctes de leur logiciel qui ne fonctionneraient que sur des prototypes ou sur des JDK d'une future version.