Java serait équipé d’une API pour sauvegarder l’état, selon une proposition flottante dans la communauté OpenJDK comme moyen d’accélérer les temps de démarrage.
Proposé dans un groupe de discussion OpenJDK par Anton Kozlov, ingénieur logiciel senior chez le fournisseur de logiciels Java Azul, le projet CRaC (Coordinated Restore at Checkpoint) rechercherait une API Java pour la coordination entre une application et l’exécution pour enregistrer et restaurer l’état. Selon la proposition, l’environnement d’exécution Java prendrait en charge plusieurs manières de sauvegarder l’état : instantané de machine virtuelle, instantané de conteneur, projet CRIU (Checkpoint/Restore In Userspace) sur Linux et d’autres moyens.
Les applications Java peuvent éviter les longs démarrages et préchauffages en sauvegardant l’état de l’environnement d’exécution Java, indique la proposition. L’état enregistré serait utilisé pour démarrer les instances rapidement. Mais la proposition cite également des défis. Une fois l’état sauvegardé, l’environnement d’exécution peut changer. De plus, si plusieurs instances sont démarrées simultanément à partir de l’état enregistré, elles devraient obtenir une certaine unicité et leurs exécutions devraient diverger à un moment donné.
La proposition indique que le moyen pratique de résoudre ces problèmes consiste à informer les applications Java du moment où l’état est enregistré et restauré. Ensuite, une application sera capable de gérer les changements environnementaux. De plus, l’application sera en mesure d’obtenir l’unicité de l’environnement.
Selon la proposition, une API serait conçue qui soit suffisamment générale pour tout mécanisme sous-jacent. En outre, des contrôles de sécurité seraient explorés dans l’API et l’environnement d’exécution qui empêcheraient la sauvegarde de l’état s’il ne peut pas être restauré ou fonctionner correctement après la restauration.
On s’attend à ce que l’API soit développée dans le cadre du processus JEP (JDK Enhancement Proposal) et intégrée dans 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, attendue pour septembre, a déjà été gelée. Dans un commentaire sur la proposition, il a été suggéré que l’effort pourrait être synchronisé avec une proposition similaire chez Red Hat. Des synergies possibles avec le projet Leyden, pour résoudre les problèmes de Java, ont également été notées.
Pour faciliter l’adoption de l’API, les plans prévoient la mise à disposition d’une bibliothèque de compatibilité org.crac. Cette bibliothèque permettrait l’utilisation de l’API CRaC avant qu’elle n’apparaisse dans le JDK principal. Lors de l’exécution sur une version JDK qui ne prend pas en charge CRaC ou l’API, la couche API org.crac agirait comme une couche « no-op » qui ne fait rien d’utile, mais lors de l’exécution sur une version JDK qui inclut les capacités CRaC, la fonctionnalité seraient exposés et utilisables via les API org.crac, sans qu’aucune modification ne soit requise pour le code utilisant l’API.
Ainsi, la couche API org.crac permettrait aux utilisateurs de commencer à coder vers les API CRaC sans les obliger à créer des versions distinctes de leur logiciel qui ne fonctionneraient que sur des prototypes ou sur des JDK à partir d’une future version.
Copyright © 2021 IDG Communications, Inc.