Red Hat publie Mandrel, une distribution Java qui compile les applications Java directement en code machine natif

Pour un démarrage plus rapide en utilisant moins de mémoire

Le 3 juillet 2020 à 12:50, par Bill Fassinou

275PARTAGES

Red Hat et la communauté GraalVM ont conjointement mis en place une nouvelle distribution Java en aval de GraalVM, appelé Mandrel. Selon la société, cette distribution alimentera la version Red Hat de Quarkus, un framework Java natif de Kubernetes pour la JVM et la compilation native. Quarkus fournit une solution efficace pour l'exécution d'applications Java sans serveur, de microservices, de conteneurs, de Kubernetes, de FaaS ou de cloud. Mandrel est open source et est disponible sur GitHub, mais il ne présente pas encore de distribution binaire.

Selon une note de Mark Little, directeur principal de l'ingénierie de Red Hat, Mandrel peut être décrit comme une distribution d'un OpenJDK standard avec une image native GraalVM spécialement packagée. L’objectif principal derrière l'introduction de Mandrel par Red Hat est d'améliorer la vitesse et l'efficacité du framework Quarkus. Il s’agit d’un framework qui offre à la fois un développement local avec un rechargement rapide et une distribution conteneurisée ou sans serveur aux fournisseurs de cloud computing.

Quarkus met l'accent sur la capacité de construire des exécutables natifs qui démarrent plus rapidement et qui réduisent aussi les coûts et les ressources opérationnels du cloud. En effet, Red Hat a expliqué que pour Quarkus, l'élément important de GraalVM est sa fonction d'image native qui produit des exécutables natifs, ce qui est une caractéristique clé pour rendre Java compétitif dans les charges de travail natives du cloud. Ainsi, Mandrel permet d'avoir GraalVM en plus de l'OpenJDK 11 dans Red Hat Enterprise Linux et d'autres distributions de l'OpenJDK 11.

Selon Red Hat, la différence pour l'utilisateur est minime, mais pour la maintenabilité, l'alignement en amont avec OpenJDK 11 et GraalVM est essentiel. « Avec Mandrel, les clients Red Hat et la communauté GraalVM bénéficient d'un développement réellement ouvert, et Red Hat peut soutenir ses clients avec des mécanismes éprouvés tout en redonnant aux communautés en amont sur lesquelles elle compte pour continuer à faire progresser l'état de l'art de l'informatique à source ouverte », a déclaré la société parlant de Mandrel.
Sur le plan des performances, GraalVM se distingue par un temps de démarrage 50 fois plus rapide et une utilisation de la mémoire 5 fois plus faible.

Ces différents tests ont été faits en utilisant une version précédente du framework Quarkus contre le mode HotSpot de Java. Bien que cette amélioration nécessite un temps de compilation plus long, elle peut être utilisée parallèlement au déploiement des fonctions Lambda et Azure de Quarkus. En outre, le référentiel GitHub de Mandrel n’offre pas encore de distribution binaire. À défaut, les utilisateurs compilent eux-mêmes le JDK en suivant les instructions à propos. Par ailleurs, James Ward, développeur logiciel, a évalué en détail GraalVM et a présenté ses avantages sur l'amélioration des performances ainsi que certains gotchas, tels que les applications qui reposent sur la réflexion.

Selon lui, cela crée un problème pour les images natives de GraalVM parce que la réflexion se produit au moment de l'exécution, ce qui rend difficile pour un compilateur AOT (Ahead-of time) de déterminer les chemins d'exécution. En ce qui concerne les applications qui n'ont pas besoin de réflexion, la page d'accueil de Quarkus vise directement l’avantage : 12 Mo de RAM contre 73 Mo (une diminution de 83 %) et 0,016 seconde à la première réponse contre 0,943 (une diminution de 98 %). Les développeurs peuvent maintenant utiliser Mandrel avec leur propre build, ou peuvent s'appuyer sur la communauté GraalVM ou toute distribution du JDK 11 et supérieure. Selon d’autres avis, ces frameworks natifs de Java ne fonctionnent pas vraiment et ne devraient pas devenir une norme dans l'industrie.

Selon eux, il ne s'agit pas d'une technologie d'usage général où l'on peut prendre une application Java existante et la rendre native. Cela ne fonctionnera pas, même pour les applications que l'on écrit en choisissant une bibliothèque dans le vaste écosystème Java. Ces derniers estiment que plusieurs fournisseurs de frameworks parient sur le fait que la plupart des applications Java sont des applications HTTP/ORM/JSON, avec en plus des mesures et de la sécurité, etc. Donc, si le framework fournit une fermeture transitive de ces bibliothèques et fournit une configuration pour compiler en natif, cela fonctionnera. Mais malheureusement, cela ne fonctionne pas, car il y a beaucoup d'autres dépendances qui ne rentrent pas dans le cadre ci-dessus.

Sources : Référentiel GitHub de Mandrel, James Ward

Et vous ?