Compilation native dans Quarkus - pourquoi c'est important

Bonjour à tous! Ceci est le deuxième article de notre série Quarkus - aujourd'hui, nous parlerons de la compilation native. (Soit dit en passant, inscrivez-vous et accédez à notre webinaire « This is Quarkus - Kubernetes native Java framework », qui se tiendra le 27 mai. Nous montrerons comment recommencer à zéro ou transférer des solutions prêtes à l'emploi)



Quarkus est une pile Java conçue pour Kubernetes. Et bien que, bien sûr, il reste beaucoup à faire ici, nous avons bien travaillé sur de nombreux aspects, y compris l'optimisation de la JVM et un certain nombre de cadres. L'une des caractéristiques de Quarkus qui a suscité un intérêt accru de la part des développeurs était une approche transparente complète pour transformer le code Java en fichiers exécutables pour un système d'exploitation spécifique (la soi-disant "compilation native"), similaire à C et C ++, où une telle compilation se produit généralement à la fin d'un cycle d'assemblage, de test et de déploiement.

Bien que la compilation native, comme nous le montrons ci-dessous, soit importante, il convient de noter que Quarkus fonctionne vraiment bien sur la machine Java OpenJDK Hotspot la plus courante, grâce aux améliorations de performances que nous avons mises en œuvre tout au long de la pile. Par conséquent, la compilation native doit être considérée comme un bonus supplémentaire qui peut être utilisé à volonté ou en cas de besoin. En fait, en ce qui concerne les images natives, Quarkus s'appuie fortement sur OpenJDK. Et le mode dev, chaleureusement accueilli par les développeurs, fournit des tests presque instantanés des changements dus aux fonctionnalités développées d'exécution de code dynamique implémentées dans Hotspot. De plus, lors de la création d'images GraalVM natives, la bibliothèque de classes OpenJDK et les fonctionnalités HotSpot sont utilisées.

Alors pourquoi avez-vous besoin d'une compilation native si tout est déjà parfaitement optimisé? Nous essaierons de répondre à cette question ci-dessous.

Commençons par l'évidence: Red Hat possède une vaste expérience dans l'optimisation des JVM, des piles et des frameworks pendant le développement du projet JBoss , notamment:

• La première application de serveur cloud à s'exécuter sur la plate-forme Red Hat OpenShift .
• Le premier serveur d'applications à s'exécuter sur les ordinateurs Plug PC .
• Le premier serveur d'applications à s'exécuter sur le Raspberry Pi .
• Un certain nombre de projets exécutés sur des appareils Android .

Nous nous occupons des problèmes liés à l'exécution d'applications Java dans le cloud et sur des appareils aux ressources limitées (lecture, IoT) depuis de nombreuses années et avons appris à tirer le maximum de la JVM en termes de performances et d'optimisation de la mémoire. Comme beaucoup d'autres, nous travaillons depuis longtemps avec la compilation native d'applications Java via GCJ , Avian , Excelsior JET et même Dalvik et sommes bien conscients des avantages et des inconvénients de cette approche (par exemple, le dilemme de choisir entre la polyvalence «construire une fois - exécuter n'importe où» et que les applications compilées sont plus petites et s'exécutent plus rapidement).

Pourquoi est-il important de considérer ces avantages et inconvénients? Parce que dans certaines situations, leur ratio devient crucial:

• , serverless/ , ( ) , . , . JVM , , , 5 . , Java- ( , , OpenWhisk Knative), JVM . , , .
• , , . , JVM , , Linux’ – . Java-. , JVM, . , .
• , - , . 12 , Kubernetes Java- . , , , , . , dead-code elimination, ( JDK), . Quarkus .

En fait, les arguments ci-dessus suffisent déjà pour comprendre la justification de la compilation native du point de vue des participants au projet Quarkus. Cependant, il y a une autre raison, non technique, mais aussi importante: ces dernières années, de nombreux programmeurs et sociétés de développement ont abandonné Java au profit de nouveaux langages de programmation, estimant que Java, avec sa JVM, ses piles et ses frameworks, est devenu trop vorace en termes de mémoire, trop lent etc.

Cependant, l'habitude d'utiliser le même outil pour résoudre les problèmes n'est pas toujours la bonne. Parfois, il vaut mieux prendre du recul et chercher autre chose. Et si Quarkus fait réfléchir et réfléchir, c'est bon pour tout l'écosystème Java. Quarkus incarne une perspective innovante sur la façon de créer des applications plus efficaces, rendant Java plus pertinent pour les nouvelles architectures d'applications comme sans serveur. De plus, en raison de son extensibilité, Quarkus, nous l'espérons, acquerra un écosystème complet d'extensions Java, augmentant considérablement le nombre de frameworks prêts à l'emploi prenant en charge la compilation native dans le cadre des applications.