¿Porqué adoptar Quarkus con código imperativo?

En los últimos años, muchos equipos están migrando sus aplicaciones Spring Boot hacia Quarkus, atraídos por su rendimiento nativo, tiempos de arranque ultrarrápidos y bajo consumo de memoria.
Sin embargo, durante una de estas migraciones, algunos han tomado una decisión interesante:

Optar por mantener código imperativo, en lugar de pasarse al modelo reactivo.

¿La razón? Veamos por qué, en el contexto actual de Java 21 y los Virtual Threads, esta decisión no solo tiene sentido, sino que puede ser la más estratégica.

1. El modelo imperativo sigue vivo (y más fuerte que nunca)

El modelo imperativo es el que los desarrolladores Java han usado por décadas:
código secuencial, sencillo de leer, depurar y mantener.
Cada request se ejecuta en un hilo, y el flujo es fácil de seguir.

Por otro lado, el modelo reactivo (basado en librerías como Mutiny o Reactor) ofrece grandes beneficios en sistemas altamente concurrentes, pero introduce una complejidad adicional:

• Composición asíncrona con Uni o Flux

• Propagación de errores no lineal

• Depuración menos intuitiva

Durante una migración, ese cambio de paradigma puede ser un obstáculo importante. Por eso, muchos equipos prefieren mantener el estilo clásico, especialmente cuando el foco está en migrar de plataforma, no en reentrenar al equipo.

2. Compatibilidad y estabilidad del ecosistema

La mayoría de las librerías Java —como JDBC, JPA, Feign o SDKs de terceros— fueron diseñadas de forma bloqueante.
Adoptar un modelo reactivo en Quarkus implica cambiar gran parte del stack:

• JDBC → Vert.x Reactive SQL Client

• Hibernate ORM → Hibernate Reactive

• JAX-RS → Mutiny + Reactive REST

En cambio, con código imperativo, el equipo puede reutilizar sus librerías existentes y minimizar el riesgo técnico.
Esto reduce drásticamente el tiempo de migración y asegura un comportamiento predecible.

3. El factor decisivo: los Virtual Threads (Project Loom)

Aquí está la gran revolución que cambió el juego.
Con Java 21, los Virtual Threads (del proyecto Loom) permiten ejecutar miles de hilos ligeros sin los costos tradicionales del modelo bloqueante.

Antes:

Cada request consumía un thread del sistema operativo.
Para escalar, necesitabas código reactivo.

Ahora:

Los Virtual Threads hacen posible manejar miles de requests concurrentes,
manteniendo código imperativo, limpio y sencillo.

En otras palabras, ya no es necesario escribir código reactivo para escalar.

4. Quarkus + Virtual Threads = Imperativo escalable

A partir de Quarkus 3.8+, el framework soporta nativamente Virtual Threads.
Solo basta con activar la siguiente propiedad:

quarkus.thread-pool.virtual-threads.enabled=true

Y listo: tus endpoints REST y llamadas JDBC bloqueantes se ejecutan de forma no bloqueante bajo el capó.
Así obtienes el rendimiento del modelo reactivo, sin renunciar a la simplicidad del imperativo.

5. Visualizando el cambio

Aquí una representación simple de cómo Quarkus gestiona requests imperativos con Virtual Threads:

Cada request HTTP se asigna a un Virtual Thread,
que ejecuta código bloqueante (como llamadas JDBC) sin penalizar el rendimiento.
El resultado: código limpio, eficiente y fácil de mantener.

6. Conclusión

La decisión de estas empresas de mantener código imperativo en Quarkus no fue conservadora, fue estratégica.
Gracias a los Virtual Threads, hoy podemos tener lo mejor de ambos mundos:

• La simplicidad del modelo tradicional,

• Con la escalabilidad del modelo reactivo.

En la era post-Loom, el paradigma imperativo vuelve a ser una opción de primera clase para desarrollar aplicaciones modernas y altamente concurrentes con Quarkus.

Autor: José Díaz

Consultor Java / Arquitecto de Software
joedayz.pe | jeftoken.com