Peu de temps après la sortie de Helidon 1.0 , Oracle a annoncé la prise en charge par Helidon de GraalVM, qui convertit les applications Helidon en code exécutable natif via l'utilitaire native-image.
Nommé à l'origine J4C (Java for Cloud) et introduit pour la première fois en septembre 2018, Helidon a été conçu pour être simple et rapide, et se compose de deux versions : Helidon SE et Helidon MP. Helidon SE dispose de trois API principales - un serveur Web, la configuration et la sécurité - pour la création d'applications basées sur des microservices. Un serveur d'application n'est pas requis. Helidon MP MicroProfile 1.2 pour la création d'applications basées sur des microservices avec les API MicroProfile prises en charge.
GraalVM, créé par Oracle Labs, est une machine virtuelle et une plateforme polyglotte pouvant être intégrée aux applications Helidon. GraalVM est composé de Graal , un compilateur just-in-time écrit en Java, de SubstrateVM, un framework permettant la compilation ahead-of-time d'applications Java en images exécutables, et de Truffle, un toolkit open source et une API permettant de créer des interpréteurs de langage.
Seules les applications Helidon SE peuvent tirer parti de GraalVM en raison de l'utilisation de la réflexion dans CDI 2.0 ( JSR 365 ), une API de base de MicroProfile. Par conséquent, Oracle Labs a décidé de ne pas inclure la prise en charge de GraalVM pour Helidon MP.
L'exemple quickstart d'Helidon SE inclut un goal Maven pour l'utilitaire GraalVM native-image et des fichiers Docker pour convertir l'application en code exécutable natif. Cet exemple a été testé avec Helidon 1.1.2 et GraalVM 19.1.1, les dernières versions de chacun.
$ export GRAALVM_HOME=/usr/local/bin/graalvm-ce-19.1.1/Contents/Home
$ mvn package -Pnative-image
Cela générera le fichier JAR habituel ( helidon-quickstart-se.jar) et l'image native executable ( helidon-quickstart-se), chacun pouvant être lancé de la manière suivante :
$ java -jar target/helidon-quickstart-se.jar
$ ./target/helidon-quickstart-se
Une installation de GraalVM n'est pas nécessaire pour utiliser le profil Docker:
$ docker build -t helidon-native -f Dockerfile.native .
$ docker run --rm -p 8080:8080 helidon-native:latest
Comme indiqué ci-dessous, le serveur web est démarré avec un fichier exécutable natif helidon-quickstart-se, généré par GraalVM.
Dmitry Kornilov, responsable principal du développement logiciel chez Oracle, a évoqué l'utilisation d'exécutables natifs dans des applications à exécution longue, en écrivant:
D'autre part, tout est toujours un compromis. Les applications de longue durée sur les JVM traditionnelles affichent toujours de meilleures performances que les exécutables natifs de GraalVM en raison de l'optimisation à l'exécution. Le mot clé ici est long ; pour les applications de courte durée telles que les fonctions serverless, les exécutables natifs ont un avantage en termes de performances. Vous devez donc choisir vous-même entre un temps de démarrage rapide et une petite taille (et l'étape supplémentaire consistant à générer l'exécutable natif) par rapport à de meilleures performances pour les applications de longue durée.
Dmitry Kornilov s'est entretenu avec InfoQ à propos d'Helidon et de GraalVM, y compris plus de détails sur les applications à longue durée de vie ou à courte durée d'exécution:
InfoQ : Peux tu expliquer pourquoi les performances dans les applications de longue durée sont meilleures avec une JVM traditionnelle que sur un exécutable natif construit avec GraalVM.
Dmitry Kornilov : Les performances ont été améliorées grâce à la compilation JIT et à l'optimisation des performances d'exécution. La JVM contient des informations d'exécution non disponibles pour le compilateur statique. Il utilise ces informations pour optimiser en permanence les applications et s'exécuter plus efficacement. L'optimisation à l'exécution prend un certain temps. Les applications compilées statiquement présentent des performances supérieures immédiatement après le démarrage de l'application. Mais au fil du temps, lorsque les optimisations à l'exécution sont effectuées, les applications basées sur la JVM commencent à démontrer de meilleures performances.
Les images natives sont idéales pour les applications de courte durée, telles que les fonctions où le temps de démarrage est critique. Pour les services de longue durée, pour lesquels le temps de démarrage n'est pas si critique, la JVM qui propose des optimisations à l'exécution est préférable. Aussi, ne vous laissez pas berner avec les temps de démarrage. Mon exemple d'application démarre une minute et demie plus lentement sur mon portable que la même application compilée sous forme d'image native. Cependant, la différence est négligeable si on la compare au temps de démarrage d'un pod Kubernetes, par exemple.
InfoQ : Helidon prend actuellement en charge MicroProfile 1.2. Avec la récente version de MicroProfile 3.0, existe-t-il un plan pour atteindre progressivement l'objectif consistant à prendre en charge une version plus récente de MicroProfile ?
Dmitry Kornilov : La prise en charge de MicroProfile 2.2 est déjà dans le master et nous apportons quelques ajustements finaux avant la sortie. MicroProfile 3.0 contient des modifications incompatibles avec les versions antérieures. Nous devrons donc probablement publier une nouvelle version majeure de Helidon pour la prendre en charge. Nous avons déjà le support d'OpenAPI 1.3 et le support pour HeathCheck 2.0 est également presque terminé. La prise en charge de Metrics 2.0 nécessite davantage de travail et nous l'évaluons et l'estimons actuellement. Je pense que nous ajouterons le support MicroProfile 3.0 avant la fin de 2019.
InfoQ : Qu'y a-t-il à l'horizon pour Helidon ?
Dmitry Kornilov : Nous travaillons sur beaucoup de choses. HTTP multipart et le support complet de HTTP/2 sont à venir. Nous travaillons également sur Helidon DB Client, qui permettra d'utiliser les bases de données JDBC de manière réactive dans Helidon SE.
Nous améliorons également la prise en charge de JPA et JTA dans Helidon MP et nous avons récemment ajouté la prise en charge de UCP (Universal Connection Pool), qui inclut des fonctionnalités de continuité. Nous venons tout juste de commencer à travailler sur la messagerie réactive et le support d'événements, mais il est trop tôt pour en parler maintenant. En passant, plusieurs sessions Helidon sont acceptées pour Oracle Open World et CodeOne. Si vous y assistez, ne manquez pas ces sessions car nous vous fournirons plus de détails sur les fonctionnalités et les projets futurs de Helidon.
Ressources
- Helidon Takes Flight par Dmitry Kornilov (7 septembre 2018)
- Oracle Introduces Helidon - A Lightweight Java Microservices Framework par InfoQ (10 octobre 2018)
- Helidon V1 Brings API Stability and MicroProfile 1.2 Support par InfoQ ((12 mars 2019)
- Helidon Flies Faster with GraalVM par Dmitry Kornilov (17 avril 2019)
- GraalVM 19.0: the Anticipated GA Release par InfoQ (17 juin 2019)