Le début de l'année a apporté une nouvelle capacité au mode développement de Quarkus : le rechargement préservant l'état. Elle a été livrée dans Quarkus 1.11+ et offre des temps de rechargement presque instantanés, préservant le précédent état. Quarkus promet des temps de rechargement et de terminaison stupéfiants ainsi qu'une efficacité accrue lors du développement d'une application via le mode développement, un mécanisme de redéploiement à chaud grâce auquel les modifications de code dans une application seront recompilées et rechargées lors de l'actualisation dans le navigateur. Conçu pour l'ère du cloud, il peut également être utilisé sur des conteneurs distants, offrant un mode de développement à distance.
InfoQ a contacté Stuart Douglas, ingénieur logiciel principal chez Red Hat, pour une meilleure compréhension du mode développement de Quarkus.
InfoQ : Merci d'avoir pris le temps de répondre aux questions de nos lecteurs. Quelles sont tes responsabilités actuelles chez Red Hat, c'est-à-dire que fais-tu au quotidien ?
Stuart Douglas :
Je travaille à plein temps sur Quarkus, principalement sur les couches core et HTTP. Au jour le jour, c'est à peu près le mélange habituel de correction de bugs et de travail sur de nouvelles fonctionnalités. Je travaille depuis l'Australie et je suis le seul de l'équipe dans mon fuseau horaire, ce qui signifie que toutes les réunions impliquent des nuits très tardives.
InfoQ : la fonction de déploiement à chaud du mode développement de Quarkus est très utile, en particulier avec les applications qui nécessitent beaucoup de temps pour se redéployer. Comment les développeurs activent-ils cette fonctionnalité ?
Stuart Douglas :
Le mode développement fait partie du cœur de Quarkus, donc chaque application Quarkus peut l'utiliser. Lancer `mvn quarkus:dev` ou` gradle quarkusDev` suffit pour le lancer. Chaque application qui utilise Quarkus devrait pouvoir utiliser le mode développement. De plus, si vous avez une classe principale que vous exécutez à partir d'un IDE, elle fonctionnera également dans cet environnement. Nous avons même une assistance pour cela maintenant avec JBang.
InfoQ : Quelles sont vos recommandations lors de l'utilisation de cette fonctionnalité ? Comment fait-il face à une instance de plusieurs changements de code ? Y a-t-il des limites à son utilisation ?
Stuart Douglas :
L'application n'est pas rechargée tant que vous n'avez pas actualisé votre navigateur. Par conséquent, si vous avez plusieurs fichiers modifiés, elle ne tentera pas de les compiler et de les recharger tant que vous ne les actualiserez pas. La seule vraie limitation est que vous ne pouvez pas recharger en direct les extensions Quarkus elles-mêmes, donc si vous avez un projet qui contient également une extension Quarkus, une partie de votre projet ne sera pas rechargeable (c'est un peu un cas secondaire, en général nous ne recommandons pas d'inclure une extension dans un projet).
InfoQ : Pouvez-vous nous présenter un aperçu de la mise en œuvre de cette fonctionnalité ?
Stuart Douglas :
Il comporte plusieurs parties. Au lancement, Quarkus découvre la structure locale du projet, de sorte qu'il comprend réellement la structuration de votre projet et l'emplacement de tous les fichiers du projet. Tout le code qui réside dans le projet est chargé dans un ClassLoader jetable, tandis que toutes les bibliothèques, y compris Quarkus lui-même, sont chargées dans un ClassLoader différent.
Lorsqu'une requête HTTP arrive à Quarkus (par exemple, vous appuyez sur Actualiser sur votre navigateur), nous interceptons cette requête très tôt et analysons tous les fichiers sources pour voir si certains ont changé. Si tel est le cas, nous les recompilons, supprimons le ClassLoader jetable, redémarrons Quarkus avec un nouveau ClassLoader, puis laissons la requête d'origine continuer vers la version mise à jour de l'application. Cela signifie que vous voyez toujours la version la plus récente de l'application. L'actualisation de votre navigateur est le déclencheur que nous utilisons pour tenter de redémarrer.
InfoQ : Quel a été le plus grand défi technique lors du développement de la fonctionnalité de déploiement à chaud ?
Stuart Douglas :
Le faire fonctionner à partir de l'EDI était assez difficile. Quarkus est divisé en deux parties, une partie d'exécution qui se termine dans l'application finale et une partie de déploiement qui contient toutes les fonctionnalités devmode, ainsi que le code qui génère l'application finale. En général, nous n'avons que la partie d'exécution dans le classpath du projet, donc essayer d'amorcer le mode dev sans avoir réellement les classes pertinentes dans le classpath nécessitait quelques astuces.
InfoQ : comme indiqué par Max Rydahl Andersen, distinguished engineer chez Red Hat et créateur de JBang, dans son tweet, Quarkus 1.11+ ajoute une nouvelle capacité au mode développement pour détecter si une modification peut être appliquée à l'instrumentation de la JVM. Quels sont les avantages de cet ajout ? Est-il activé par défaut ?
Stuart Douglas :
Il y a deux avantages principaux car vous n'avez pas besoin de redémarrer l'application; un redémarrage basé sur l'instrumentation est beaucoup plus rapide (presque instantané), donc le seul temps consacré au rechargement est le temps de compiler les modifications. L'autre avantage est que vous pouvez conserver l'état de votre application, par ex. Hibernate, ne recréera pas la base de données, ce qui peut faire gagner du temps.
Il a été activé par défaut, cependant dans Quarkus 1.13.1 nous l'avons changé pour qu'il soit désactivé par défaut. Ce que nous avons constaté, c'est que cela peut causer une certaine confusion si vous avez du code qui s'exécute au démarrage (ou ne s'exécute qu'une seule fois lorsqu'un Singleton est créé). Étant donné que l'application n'est pas redémarrée, vos modifications ne prennent pas effet immédiatement. Pour Quarkus 2.0, nous espérons avoir un moyen très simple de l'activer et de le désactiver au moment de l'exécution (probablement via l'interface utilisateur des développeurs), afin que vous puissiez choisir le mode de votre choix et le modifier selon vos besoins en appuyant simplement sur un bouton.
InfoQ : Pouvez-vous, s'il vous plaît, partager quelques détails sur la magie de la mise en œuvre de cette nouvelle fonctionnalité du mode développement ? Y a-t-il des limitations connues dont vous êtes conscient ?
Stuart Douglas :
Lorsque Quarkus démarre en mode développement, les plug-ins Maven/Gradle ajoutent un JavaAgent à la ligne de commande pour accéder à java.lang.instrument.Instrumentation qui nous permet de modifier les classes. Après avoir compilé les classes, nous regardons la nouvelle classe et vérifions si elle a exactement la même signature que l'ancienne version (par exemple, pas de nouvelles méthodes, toutes les annotations sont les mêmes, et vérifions essentiellement que la seule chose qui a changé est le contenu des méthodes). Si cette vérification réussit, nous utilisons l'API d'instrumentation pour remplacer les classes, plutôt que de redémarrer Quarkus.
Il n'est possible d'utiliser l'instrumentation que si la signature de la classe n'a pas changé.
InfoQ : Qu'est-ce qui rend la fonctionnalité de déploiement à chaud unique par rapport à des outils similaires, tels que JRebel ?
Stuart Douglas :
La principale différence est qu'il est intégré au projet, de sorte que chaque développeur peut l'utiliser sans configuration. Une autre grande différence est que nous prenons le contrôle total de toute l'expérience, y compris la compilation, donc nous ne comptons pas sur des outils externes. L'approche basée sur HTTP pour détecter les changements (au lieu d'utiliser un minuteur) signifie que les développeurs peuvent être sûrs qu'ils pourront toujours voir les résultats les plus récents.
En mettant l'accent non seulement sur le rechargement rapide des applications, mais également sur l'amélioration de l'efficacité et du retour d'information lors de leur développement, Quarkus tente de relier les avantages de l'utilisation d'un langage mature, tel que Java et son écosystème, et les avantages d'une boucle de rétroaction rapide caractéristique trouvée principalement sur les langages de script comme Python et JavaScript.