# ¿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**.

| Aspecto | Reactivo (Mutiny/Vert.x) | Imperativo + Virtual Threads |
| --- | --- | --- |
| Modelo | Asíncrono y funcional | Secuencial y clásico |
| Escalabilidad | Alta | Alta |
| Complejidad | Alta | Baja |
| Compatibilidad con librerías | Parcial | Total |
| Depuración | Difícil | Sencilla |
| Requiere reescritura | Sí | No |

## 5\. Visualizando el cambio

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1762499678641/c4708226-fafb-4573-8571-e674a5ba638d.png align="center")

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](https://joedayz.pe) | [jeftoken.com](https://jeftoken.com)