{"id":76573,"date":"2020-04-03T13:42:25","date_gmt":"2020-04-03T11:42:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nativnaya-kompilyacziya-v-quarkus-pochemu-eto-vazhno"},"modified":"2020-04-03T13:42:25","modified_gmt":"2020-04-03T11:42:25","slug":"nativnaya-kompilyacziya-v-quarkus-pochemu-eto-vazhno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/nativnaya-kompilyacziya-v-quarkus-pochemu-eto-vazhno","title":{"rendered":"Compilation native dans Quarkus \u2013 pourquoi est-ce important","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous ! Voici le deuxi\u00e8me article de notre s\u00e9rie sur Quarkus \u2013 aujourd'hui, nous allons parler de la compilation native.<\/p>\n

\"Compilation
\n
\nQuarkus<\/a><\/noindex> \u2013 est une pile Java con\u00e7ue pour Kubernetes<\/a><\/noindex>. Et bien qu'il reste encore beaucoup \u00e0 faire ici, nous avons bien travaill\u00e9 sur de nombreux aspects, y compris l'optimisation de la JVM et de plusieurs frameworks. L'une des caract\u00e9ristiques de Quarkus qui a suscit\u00e9 un vif int\u00e9r\u00eat parmi les d\u00e9veloppeurs est son approche int\u00e9gr\u00e9e et transparente pour transformer le code Java en fichiers ex\u00e9cutables pour un syst\u00e8me d'exploitation sp\u00e9cifique (ce que l'on appelle la \u00ab compilation native \u00bb) par analogie avec C et C++, o\u00f9 cette compilation a g\u00e9n\u00e9ralement lieu \u00e0 la fin d'un cycle de construction, de test et de d\u00e9ploiement.
\n<\/a><\/noindex>
\nEt bien que la compilation native, comme nous allons le montrer ci-dessous, soit importante, il est bon de noter que Quarkus fonctionne effectivement tr\u00e8s bien m\u00eame sur une machine Java classique avec OpenJDK Hotspot gr\u00e2ce aux am\u00e9liorations de performance que nous avons r\u00e9alis\u00e9es dans toute la pile. Par cons\u00e9quent, la compilation native doit \u00eatre envisag\u00e9e comme un bonus suppl\u00e9mentaire que l'on peut utiliser par pr\u00e9f\u00e9rence ou n\u00e9cessit\u00e9. En fait, en ce qui concerne les images natives, Quarkus s'appuie dans une large mesure sur OpenJDK. De plus, le mode dev, tr\u00e8s bien accueilli par les d\u00e9veloppeurs, permet de tester presque instantan\u00e9ment les changements gr\u00e2ce \u00e0 des capacit\u00e9s avanc\u00e9es d'ex\u00e9cution dynamique du code mises en \u0153uvre dans Hotspot. En outre, lors de la cr\u00e9ation d'images natives, GraalVM utilise la biblioth\u00e8que de classes d'OpenJDK et les capacit\u00e9s de HotSpot.<\/p>\n

Alors, pourquoi la compilation native est-elle n\u00e9cessaire, si tout est d\u00e9j\u00e0 si bien optimis\u00e9 ? C'est la question \u00e0 laquelle nous allons tenter de r\u00e9pondre ci-dessous.<\/p>\n

Commen\u00e7ons par l'\u00e9vidence : Red Hat poss\u00e8de une vaste exp\u00e9rience dans l'optimisation de la JVM, des piles et des frameworks au cours du d\u00e9veloppement du projet JBoss<\/a><\/noindex>, y compris :<\/p>\n