Java serait équipé d’une API pour conserver l’état, selon une proposition flottant dans le voisinage 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 travail CRaC (Restauration coordonnée au point de contrôle) examinerait une API Java pour la coordination entre une application et l’exécution afin de sauvegarder et de restaurer l’état. Selon la proposition, l’environnement d’exécution Java prendrait en charge plusieurs façons de conserver l’état : photo de fabricant virtuel, instantané de conteneur, projet CRIU (Checkpoint/Restore In Userspace) sur Linux et d’autres méthodes.
Sur L « Entrepreneur : les développeurs réagissent au copilote GitHub]
Les applications Java peuvent empêcher le démarrage et le préchauffage longs en sauvegardant l’état de l’environnement d’exécution Java, indique la proposition. L’état conservé serait utilisé pour démarrer les circonstances rapidement. Mais la proposition cite aussi des difficultés. Une fois l’état réellement conservé, l’environnement d’exécution peut changer. De même, si plusieurs instances sont lancées simultanément à partir de l’état conservé, elles devraient obtenir une certaine unicité et leurs exécutions doivent diverger à un moment donné.
La proposition mentionne que la manière pratique de résoudre ces problèmes est de faire Java les applications savent quand l’état est enregistré et restauré. Une application sera capable de gérer les changements écologiques. De plus, l’application aura la capacité d’obtenir l’unicité de l’environnement.
Dans le cadre de la proposition, une API suffisamment générale pour tout mécanisme sous-jacent serait conçue. De même, des contrôles de sécurité seraient explorés dans l’API et le runtime qui empêcheraient la conservation de l’état s’il ne peut pas être ramené ou fonctionner correctement après le retour. On s’attend à ce que l’API soit développée dans le cadre du processus JEP (JDK Improvement Proposal) et du standard Java adapté, mais aucune variante particulière de Java n’a encore été ciblée pour l’API. L’ensemble de fonctions de la prochaine version de Java, JDK 17, attendu pour septembre, a déjà été gelé. 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 Task Leyden, pour résoudre les problèmes d’inconfort de Java, ont également été notées.
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 du fonctionnement sur une version JDK qui ne prend pas en charge CRaC ou l’API, la couche API org.crac servirait de couche « no-op » qui ne fait rien d’utile, cependant lorsque vous travaillez sur une version JDK qui inclut des capacités CRaC, les performances serait exposé et fonctionnel via les API org.crac, sans aucune modification nécessaire au code utilisant l’API.
Par conséquent, 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 application logicielle qui ne traiteraient que des modèles ou sur JDK d’une future version.
Toute l’actualité en temps réel, est sur L’Entrepreneur
