En el universo Java, que una aplicación inicie en pocos milisegundos con un consumo mínimo de memoria ha dejado de ser ciencia ficción. Gracias a GraalVM, Mandrel, y sus tecnologías, hoy es posible hacerlo realidad. En este artículo las desarmaremos para entender sus tecnologías, componentes, y cómo Quarkus puede empaquetar tu aplicación como un archivo ejecutable que no requiere JVM 🤯.
¿Qué es GraalVM?
GraalVM es una plataforma de ejecución de alto rendimiento desarrollada por Oracle Labs. Aunque fue diseñada para soportar múltiples lenguajes, en el contexto de Java moderno, además de funcionar como una JVM tradicional, destaca por ofrecer algo revolucionario: la posibilidad de compilar aplicaciones Java como ejecutables nativos, o sea, generando un único archivo ejecutable destinado a una arquitectura de hardware y sistema operativo específicos.
Esto propuso una idea totalmente disruptiva: que una aplicación Java pudiera convertirse en un ejecutable nativo, que arranque en milisegundos, con menos consumo de memoria, y que ya no necesite una JVM instalada — ideal para entornos Cloud-Native y funciones serverless.
Esta capacidad de transformar cualquier aplicación Java en un único archivo ejecutable autocontenido y compacto se logra con componente fundamental de GraalVM que se convirtió en una pieza clave de Quarkus: native-image.
El papel de native-image
Este componente permite transformar tu aplicación Java y sus dependencias en un ejecutable completamente nativo. Lo logra mediante un exhaustivo análisis estático del código durante el proceso de compilación, examinando tu aplicación a fondo para identificar y seleccionar únicamente las clases, métodos y recursos que son estrictamente necesarios para su ejecución, descartando cualquier elemento superfluo. El resultado de este proceso es una aplicación altamente optimizada que destaca por sus arranques ultrarrápidos, un consumo mínimo de memoria y un comportamiento excepcionalmente predecible.
Pero hay más, native-image no está solo, porque dentro de cada ejecutable nativo agrega un componente clave: SubstrateVM, el runtime liviano que permite que estos ejecutables nativos se ejecuten.
SubstrateVM: el runtime invisible 🤫
SubstrateVM es una máquina virtual nativa que forma parte de GraalVM, diseñada específicamente para ejecutar aplicaciones Java compiladas como ejecutables nativos (en lugar de bytecode sobre la JVM tradicional). Este núcleo de ejecución se integra dentro del ejecutable nativo generado por native-image.
Está escrito en Java y se compila junto con tu aplicación para convertirse en un runtime autónomo. Incluye su propio recolector de basura, un scheduler de hilos simplificado y soporte parcial del JDK (sólo lo necesario para tu app). Sin embargo, esta ligereza tiene un costo: algunas características de Java, como la reflexión dinámica o la carga de clases en tiempo de ejecución, no están disponibles por defecto.
SubstrateVM es, en definitiva, el motor silencioso que impulsa los ejecutables nativos generados por GraalVM o Mandrel, y forma parte de una imagen nativa completa construida con native-image.
¿Qué es Mandrel?
Mandrel es una distribución especializada y reducida de GraalVM, mantenida por Red Hat y centrada exclusivamente en la funcionalidad de compilación nativa (native-image).
Basada en GraalVM Community Edition, se ajusta para maximizar la compatibilidad y el rendimiento con Quarkus y Red Hat Build of Quarkus (RHBQ). A diferencia de la distribución estándar de GraalVM, Mandrel excluye componentes no esenciales (como el soporte a otros lenguajes) y se construye exclusivamente sobre el proyecto estándar OpenJDK –omitiendo algunas pequeñas mejoras que Oracle ha agregado a la versión de OpenJDK utilizada para construir GraalVM– consolidando así su naturaleza 100% open source.
Mandrel se recomienda para crear ejecutables nativos que se dirigen a entornos en contenedores de Linux. Esto la convierte en una opción recomendada para entornos empresariales, despliegues en OpenShift y cualquier escenario donde se priorice la estabilidad, trazabilidad y cumplimiento de normativas. Mandrel también incluye SubstrateVM como parte del ejecutable resultante, pero con parches y configuraciones adaptadas específicamente a los requisitos de Quarkus.
¿Qué sucede al compilar en modo nativo con Quarkus?
Compilar aplicaciones Java a ejecutables nativos presenta un desafío tradicional: el sistema operativo y la arquitectura de hardware donde se realiza la compilación (la máquina host) deberían ser idénticos a los del entorno donde se ejecutará el ejecutable nativo (la máquina destino).
Aquí es donde Quarkus resuelve este problema de manera práctica: en lugar de realizar la compilación en tu máquina host, lo que hace es realizar la compilación nativa dentro de un contenedor Docker (o similar) que simula el entorno de destino.
Cuando ejecutas un build nativo en Quarkus —por ejemplo, con el comando:
./mvnw package -Pnative
o con:
quarkus build --native
el framework delega la tarea a la herramienta native-image. Esta toma tu código, realiza una compilación «Ahead-of-Time» (AOT) muy profunda, embebe SubstrateVM, aplica las configuraciones necesarias y genera un binario listo para ejecutarse sin necesidad de una JVM instalada. Si la compilación se realiza dentro de un contenedor, native-image genera el ejecutable para el sistema operativo y la arquitectura del propio contenedor.
Es importante destacar que, si utilizas Red Hat Build of Quarkus, el proceso automáticamente empleará Mandrel como su motor de compilación nativa. Esto no solo garantiza la compatibilidad total con OpenShift y ofrece el soporte empresarial, sino que asegura que la compilación nativa, que ocurre típicamente dentro de contenedores, se realice con una solución optimizada y con soporte completo de Red Hat.
🧭 GraalVM vs Mandrel
Ambas distribuciones comparten la capacidad de generar ejecutables nativos con SubstrateVM, pero sus objetivos son distintos. GraalVM está pensada para casos generales y exploración de múltiples lenguajes; Mandrel está enfocada en Quarkus y escenarios empresariales.
Característica | GraalVM Community | Mandrel (Red Hat) |
---|---|---|
Base tecnológica | OpenJDK + Tecnología GraalVM | OpenJDK |
Licenciamiento | Mixto (GPL + CPE) | 100% Open Source (GPL) |
Soporte múltiples lenguajes | Sí (Políglota: Java, Python, C/C++, etc.) | No (sólo Java) |
Optimizado para Quarkus | Sí (compatibilidad general) | Sí (con optimizaciones específicas) |
Soporte oficial Red Hat | ❌ No | ✅ Sí |
Una nave, múltiples motores
Una aplicación Quarkus puede parecer sencilla, pero cuando se transforma en ejecutable nativo, se convierte en una nave de alto rendimiento ensamblada con precisión. En ese proceso:
- native-image actúa como el ingeniero que la construye.
- SubstrateVM es el motor que permite despegar sin JVM.
- GraalVM o Mandrel son las tecnologías que hacen posible ese viaje.
Comprender esta arquitectura no sólo es fascinante: también es clave para tomar decisiones acertadas sobre compilación, rendimiento y despliegue en producción.
Y si alguna vez te preguntaste cuándo conviene dejar atrás la JVM y apostar por ejecutables nativos, ya exploramos esa comparación en este artículo:
👉 JAR vs ejecutable nativo en Quarkus: diferencias, ventajas y casos de uso