Compilación nativa en Quarkus: por qué es importante

¡Hola a todos! Esta es la segunda publicación de nuestra serie Quarkus: hoy hablaremos sobre la compilación nativa. (Por cierto, regístrese y vaya a nuestro seminario web “ Esto es Quarkus - Marco Java nativo de Kubernetes ”, que se llevará a cabo el 27 de mayo. Le mostraremos cómo comenzar desde cero o transferir soluciones ya



preparadas ) Quarkus es una pila de Java diseñada para Kubernetes. Y aunque, por supuesto, queda mucho por hacer aquí, hemos resuelto muchos aspectos bien, incluida la optimización de la JVM y una serie de marcos. Una de las características de Quarkus que causó mayor interés por parte de los desarrolladores fue un enfoque integral integral para convertir el código Java en archivos ejecutables para un sistema operativo específico (la llamada "compilación nativa"), similar a C y C ++, donde dicha compilación generalmente ocurre al final de un ciclo de ensamblaje, prueba e implementación.

Aunque la compilación nativa, como mostramos a continuación, es importante, debe tenerse en cuenta que Quarkus realmente funciona bien en la máquina Java OpenJDK Hotspot más común, gracias a las mejoras de rendimiento que hemos implementado en toda la pila. Por lo tanto, la compilación nativa debe considerarse como un bono adicional que se puede utilizar a voluntad o necesidad. De hecho, con respecto a las imágenes nativas, Quarkus depende en gran medida de OpenJDK. Y el modo de desarrollo, recibido con entusiasmo por los desarrolladores, proporciona pruebas casi instantáneas de los cambios debido a las características desarrolladas de ejecución de código dinámico implementadas en Hotspot. Además, al crear imágenes nativas de GraalVM, se utilizan la biblioteca de clases OpenJDK y las características de HotSpot.

Entonces, ¿por qué necesita una compilación nativa si todo ya está perfectamente optimizado? Intentaremos responder esta pregunta a continuación.

Comencemos con lo obvio: Red Hat tiene una amplia experiencia en la optimización de JVM, pilas y marcos durante el desarrollo del proyecto JBoss , que incluye:

• La primera aplicación de servidor en la nube que se ejecuta en la plataforma Red Hat OpenShift .
• El primer servidor de aplicaciones que se ejecuta en computadoras Plug PC .
• El primer servidor de aplicaciones que se ejecuta en Raspberry Pi .
• Una serie de proyectos que se ejecutan en dispositivos Android .

Hemos estado lidiando con los problemas de ejecutar aplicaciones Java en la nube y en dispositivos con recursos limitados (lectura, IoT) durante muchos años y hemos aprendido a exprimir al máximo la JVM en términos de rendimiento y optimización de memoria. Como muchos otros, hemos trabajado durante mucho tiempo con la compilación nativa de aplicaciones Java a través de GCJ , Avian , Excelsior JET e incluso Dalvik y conocemos los pros y los contras de este enfoque (por ejemplo, el dilema de elegir entre la versatilidad "construir una vez, ejecutar en cualquier lugar" y que las aplicaciones compiladas son más pequeñas y se ejecutan más rápido).

¿Por qué es importante considerar estos pros y contras? Porque en algunas situaciones, su relación se vuelve crucial:

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

En realidad, los argumentos anteriores ya son suficientes para comprender la justificación de la compilación nativa desde el punto de vista de los participantes del proyecto Quarkus. Sin embargo, hay una razón más, no técnica, sino también importante: en los últimos años, muchos programadores y compañías de desarrollo han abandonado Java en favor de nuevos lenguajes de programación, creyendo que Java, junto con su JVM, pilas y marcos, se ha vuelto demasiado voraz en términos de memoria, demasiado lento, etc.

Sin embargo, el hábito de usar la misma herramienta para resolver cualquier problema no siempre es correcto. A veces es mejor dar un paso atrás y buscar otra cosa. Y si Quarkus hace que la gente haga una pausa y piense, esto es bueno para todo el ecosistema de Java. Quarkus encarna una perspectiva innovadora sobre cómo crear aplicaciones más eficientes, haciendo que Java sea más relevante para las nuevas arquitecturas de aplicaciones como sin servidor. Además, debido a su extensibilidad, Quarkus, esperamos, adquirirá un ecosistema completo de extensiones de Java, lo que aumentará significativamente la cantidad de marcos que admitirán la compilación nativa como parte de las aplicaciones.