Jakarta EE vs Spring Boot en 2026: migré un backend de producción y los tradeoffs no son los que esperaba

Jakarta EE 11 salió con un renovado discurso de portabilidad, runtime independiente y alineación con las últimas specs de la JVM. La comunidad Java lo recibió con el entusiasmo habitual de "Spring está hinchado, ahora volvemos a los estándares". Yo también lo leí. Y después hice algo que la mayoría no hace: migré un módulo real de un backend de firma digital que tenía corriendo en producción con Spring Boot 3.x, lo porté a Payara 6 con Jakarta EE 11, medí todo lo que pude medir y documenté lo que salió mal.

Mi tesis es esta: Jakarta EE no está muerto, pero el costo de migración real es consistentemente más alto que lo que prometen los benchmarks sintéticos. Spring Boot gana en ecosistema; Jakarta EE gana en portabilidad real. Ninguno gana en todo, y la documentación oficial de ambos omite exactamente los mismos problemas.

Jakarta EE vs Spring Boot 2026: el estado real del ecosistema

Antes de cualquier número, el contexto técnico que importa:

• Spring Boot 3.x corre sobre Jakarta EE 9+ internamente (abandonó javax.* en la 3.0). Eso significa que la narrativa "Spring vs Jakarta EE" es parcialmente falsa: Spring Boot 3 ya es Jakarta EE por debajo, con una capa de abstracción arriba.
• Jakarta EE 11 (Release Notes oficiales) incorpora soporte mejorado para Virtual Threads (Project Loom), Jakarta Data 1.0 como spec nueva, y mejoras en CDI 4.1. Son cambios reales, no cosméticos.
• El debate real no es "¿cuál es mejor?" sino "¿cuándo tiene sentido pagar el costo de portabilidad?"

Ese matiz lo perdés si leés solo los benchmarks de TechEmpower o las comparativas que circulan en Reddit. Yo también los leí. Después fui a la consola.

La migración real: antes y después del módulo REST

El módulo que migré es un backend de firma digital: endpoints REST para firmar documentos, verificar certificados y gestionar tokens. Nada experimental. Código que procesa operaciones sensibles, con pruebas de integración reales y logs que importan.

Antes: Spring Boot 3.x

<!-- pom.xml antes de la migración -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <!-- Versión de Spring Boot 3.x activa al momento de la migración -->
    <version>3.3.0</version>
</parent>

<dependencies>
    <!-- Web + REST -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- Seguridad base -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <!-- JPA con Hibernate -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
    <!-- PostgreSQL driver -->
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
    </dependency>
</dependencies>

Un endpoint típico de validación de certificado se veía así:

// Spring Boot: endpoint de verificación de firma
@RestController
@RequestMapping("/api/v1/firma")
public class FirmaController {

    private final FirmaService firmaService;

    // Inyección por constructor — buena práctica
    public FirmaController(FirmaService firmaService) {
        this.firmaService = firmaService;
    }

    @PostMapping("/verificar")
    public ResponseEntity<VerificacionResponse> verificar(
            @RequestBody @Valid FirmaRequest request) {
        // El servicio levanta una excepción tipada si la firma no es válida
        var resultado = firmaService.verificar(request.getDocumento(), request.getFirma());
        return ResponseEntity.ok(new VerificacionResponse(resultado));
    }
}

Limpio, directo. Cero boilerplate extra si Spring Boot ya viene configurado.

Después: Jakarta EE 11 en Payara 6

<!-- pom.xml post-migración a Jakarta EE 11 -->
<dependencies>
    <!-- Spec completa de Jakarta EE 11 — provided porque el servidor la aporta -->
    <dependency>
        <groupId>jakarta.platform</groupId>
        <artifactId>jakarta.jakartaee-api</artifactId>
        <version>11.0.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

<!-- Nada de fat JAR: el WAR lo despliega Payara -->
<packaging>war</packaging>

El mismo endpoint en Jakarta EE 11:

// Jakarta EE 11: mismo endpoint, distinta ceremonia
@Path("/firma")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@ApplicationScoped
public class FirmaResource {

    @Inject
    FirmaService firmaService;

    @POST
    @Path("/verificar")
    public Response verificar(FirmaRequest request) {
        // Sin @Valid automático — necesitás Bean Validation explícito o interceptor CDI
        // Eso es boilerplate que Spring Boot resuelve solo
        if (request == null || request.getDocumento() == null) {
            return Response.status(Response.Status.BAD_REQUEST).build();
        }
        var resultado = firmaService.verificar(request.getDocumento(), request.getFirma());
        return Response.ok(new VerificacionResponse(resultado)).build();
    }
}

La diferencia no es dramática en este ejemplo, pero escala. Con 30 endpoints, la cantidad de configuración manual acumulada fue mayor de lo que esperaba.

Benchmark de startup en Railway: los números reales

Corrí los dos stacks en Railway (mi post de Spring Boot en producción tiene el baseline de flags JVM) con el mismo hardware virtual. Los números son orientativos y dependen del contexto, pero la tendencia fue consistente en 5 runs:

El WAR de Jakarta EE es pequeño en papel porque el servidor aporta las specs. Pero el servidor en sí es enorme. En contenedores efímeros o despliegues frecuentes, eso duela.

Las flags JVM que usé en ambos casos para alinear condiciones:

# Flags usadas en ambos stacks para comparación justa
-XX:+UseZGC \
-XX:MaxRAMPercentage=75.0 \
-XX:+UseStringDeduplication \
-Djava.security.egd=file:/dev/./urandom \
# Virtual Threads activados (disponible en ambos con JDK 21+)
--enable-preview

Con Virtual Threads, Jakarta EE 11 en Payara mostró mejor throughput bajo carga sostenida que Spring Boot sin WebFlux. Pero Spring Boot con WebFlux cierra esa brecha casi por completo. El tema de la concurrencia ya no es una ventaja exclusiva de ninguno de los dos.

Los tres problemas que ninguna guía oficial menciona

Acá está lo que buscaba cuando empecé esta migración y no encontré documentado en ningún lado.

Problema 1: CDI y el ciclo de vida en Jakarta Data 1.0 tiene edge cases con repositorios sin transacción explícita

Jakarta Data 1.0 es nueva en EE 11 (lo confirma la spec oficial) y la documentación la presenta como la respuesta a Spring Data. Lo es, en parte. Pero si tenés repositorios que ejecutan queries fuera de un contexto transaccional activo, el comportamiento no es el que la spec sugiere en los ejemplos. Me pasé dos horas diagnosticando un TransactionRequiredException que aparecía solo en el path de verificación de certificados, no en el de firma. La diferencia era que uno tenía @Transactional explícito en el servicio y el otro confiaba en que CDI lo resolvería. No lo resuelve solo.

// ❌ Esto falla silenciosamente en Payara con Jakarta Data 1.0
// si el repositorio hace una query de lectura fuera de TX activa
@ApplicationScoped
public class CertificadoService {

    @Inject
    CertificadoRepository repo; // Jakarta Data repository

    public Optional<Certificado> buscar(String serial) {
        // Sin @Transactional acá, Payara lanza excepción en runtime
        // Spring Data JPA hubiera creado la TX automáticamente
        return repo.findBySerial(serial);
    }
}

// ✅ Solución: TX explícita o anotación en el repositorio
@ApplicationScoped
public class CertificadoService {

    @Inject
    CertificadoRepository repo;

    @Transactional(Transactional.TxType.SUPPORTS) // acepta TX existente o corre sin ella
    public Optional<Certificado> buscar(String serial) {
        return repo.findBySerial(serial);
    }
}

Spring Boot según su documentación oficial crea transacciones de lectura automáticamente en los repositories de Spring Data. Es opinionado, sí. Pero en producción ese default te salva de bugs sutiles.

Problema 2: la integración con librerías de terceros asume Spring en 2026

Quise integrar una librería de firma PKI (no voy a nombrarla porque es privada, pero el patrón es universal): el SDK tenía integración nativa con Spring Boot vía @SpringBootApplication autoconfiguration. Para Jakarta EE, el README decía "ver documentación de integración manual". Esa documentación tenía tres pasos, dos de los cuales referenciaban APIs deprecadas en EE 9. Terminé escribiendo un adapter CDI propio.

Esto no es un problema de Jakarta EE como spec. Es un problema de ecosistema. El 80% de las librerías Java de nicho asumen Spring Boot. Si vas a EE puro, vas a escribir adapters. Calculá ese tiempo.

Problema 3: el logging estructurado es ciudadano de primera en Spring Boot, no en EE 11

Con Spring Boot 3.x, logging estructurado en JSON con correlación de trazas es configuración de tres líneas en application.properties. Con Jakarta EE 11 en Payara, el sistema de logging nativo (Java Util Logging) no tiene soporte out-of-the-box para JSON estructurado con MDC (Mapped Diagnostic Context). Tuve que agregar Logback manualmente como dependencia, configurar un logback.xml dentro del WAR y rezar para que Payara no interfiriera con su propio log manager.

<!-- logback.xml dentro del WAR para Jakarta EE en Payara -->
<configuration>
    <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <!-- Campos extra para correlación de trazas -->
            <customFields>{"app":"backend-firma","env":"produccion"}</customFields>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="JSON"/>
    </root>
</configuration>

Y después tuve que agregar en payara-web.xml:

<!-- payara-web.xml: delegar logging al sistema de la app, no al servidor -->
<payara-web-app>
    <log-service>
        <module-log-levels>
            <module name="com.sun.enterprise.server" value="WARNING"/>
        </module-log-levels>
    </log-service>
</payara-web-app>

Nada de esto aparece en la guía de migración oficial. Lo encontré en un hilo de Stack Overflow de 2023 y un issue de GitHub del propio Payara.

Errores comunes al comparar estos dos stacks

Error 1: Comparar fat JAR vs WAR sin contar el servidor. El WAR de Jakarta EE parece liviano, pero el servidor de aplicaciones que lo ejecuta pesa entre 150 MB y 400 MB desplegado. El fat JAR de Spring Boot incluye todo, y eso hace la comparación honesta.

Error 2: Asumir que "estándar" significa "portabilidad gratuita". Jakarta EE promete portabilidad entre servidores certificados. En la práctica, Payara y WildFly tienen diferencias de comportamiento en CDI, en el handling de errores de despliegue y en las extensiones de logging. La portabilidad existe, pero no es gratis: hay que testear contra cada servidor.

Error 3: Ignorar el costo de ecosistema. Si tu stack tiene más de cinco dependencias de terceros, hacé el ejercicio antes de migrar: buscá si cada una tiene integración nativa con Jakarta EE o si asume Spring. Este punto por sí solo puede descartar la migración sin necesidad de correr un solo benchmark. El tema de supply chain en dependencias Java tiene su propia complejidad, que toqué en un contexto diferente cuando comparé npm vs PyPI como vectores de ataque.

Error 4: Creer que los Virtual Threads solucionan la comparación de performance. Con JDK 21+ y Virtual Threads, ambos stacks pueden manejar concurrencia masiva sin el modelo reactivo tradicional. La ventaja histórica de Netty/WebFlux sobre servidores bloqueantes se achicó. Pero eso no hace a Jakarta EE más rápido en startup ni más fácil de integrar.

FAQ: Jakarta EE vs Spring Boot en 2026

¿Tiene sentido migrar de Spring Boot a Jakarta EE hoy? Depende de la razón. Si necesitás portabilidad real entre servidores de aplicaciones (escenario enterprise con cliente que exige WildFly en sus servidores propios), Jakarta EE tiene sentido. Si estás en cloud con contenedores propios, Spring Boot probablemente te ahorra semanas de configuración sin ceder nada significativo.

¿Jakarta EE 11 es superior a Spring Boot 3.x en performance? En throughput bajo carga sostenida con Virtual Threads, la diferencia es pequeña y depende del workload. En startup time y tiempo de primer request, Spring Boot con fat JAR gana claramente en entornos de contenedores efímeros. Los benchmarks sintéticos no capturan el costo de bootstrapping del servidor de aplicaciones.

¿Puedo usar Spring Boot y Jakarta EE juntos? Spring Boot 3.x ya usa Jakarta EE internamente (todo pasó de javax.* a jakarta.* en la versión 3.0). Lo que no podés hacer fácilmente es mezclar CDI de Jakarta con el contenedor de Spring en el mismo contexto. Son dos modelos de inyección de dependencias distintos.

¿Qué servidor de aplicaciones recomendás para Jakarta EE 11 en producción? Payara 6 tiene la documentación más actualizada para EE 11 y la comunidad más activa en GitHub al momento de escribir esto. WildFly tiene más historia y mejor soporte de la comunidad general. Open Liberty (IBM) es sólido para entornos enterprise pero con menos documentación en español. Ninguno tiene la experiencia de Railway que tiene Spring Boot hoy.

¿Jakarta EE Data 1.0 puede reemplazar Spring Data JPA? Parcialmente. Cubre los casos básicos de repositorios tipados. Pero Spring Data tiene cinco años más de madurez, integración con todos los stacks de Spring, y una comunidad de plugins mucho más grande. Jakarta Data 1.0 es prometedora; no es un reemplazo drop-in todavía.

¿Por qué la documentación oficial de ambos omite los mismos problemas? Porque la documentación oficial está escrita para el happy path. Los problemas de logging en contenedores Payara, los edge cases de CDI sin transacción activa, y el costo de adaptar librerías de terceros son problemas que aparecen cuando ponés el código en producción real. Ningún equipo de documentación reproduce ese escenario sistemáticamente.

Conclusión: lo que haría diferente si empezara hoy

No me arrepiento de haber hecho la migración. Aprendí cosas que no hubiera aprendido leyendo specs. Pero si alguien me pregunta si vale la pena hoy, mi respuesta es matizada:

Quedate con Spring Boot 3.x si:

• Tenés un equipo que ya conoce el ecosistema
• Usás librerías de terceros que asumen Spring
• Desplegás en contenedores propios o Railway
• El startup time importa (serverless, scaling rápido)

Evaluá Jakarta EE 11 si:

• Tenés requisitos contractuales de portabilidad entre servidores certificados
• Estás en un entorno enterprise donde WildFly o Payara ya corren en la infra del cliente
• Querés separar el código de la app del runtime con más pureza arquitectónica
• Tenés tiempo para absorber la curva de configuración manual

Lo que no haría es decidir basándome en benchmarks sintéticos. Los números que importan son los tuyos, con tu hardware, con tus dependencias. Los que yo medí son un punto de partida, no una conclusión.

Me resistí a TypeScript durante años pensando que los tipos eran burocracia. Un bug de null pointer a las 2am me convenció en 20 minutos. Con Jakarta EE me pasó algo similar: la portabilidad es real, pero el costo de adaptación también lo es. Ambas cosas pueden ser verdad al mismo tiempo.

El camino hacia Java Champion no pasa por elegir el stack correcto. Pasa por entender en profundidad ambos, saber cuándo usar cada uno, y no mentirte sobre los tradeoffs. Este post es mi contribución a esa honestidad.

Si te interesa el lado de seguridad de los sistemas de identidad digital y firma, el post sobre Themis vs Web Crypto API toca tradeoffs similares pero en TypeScript. Y si querés ver cómo quedó mi arquitectura de JVM flags antes de esta migración, está documentado en Spring Boot en producción: lo que la documentación oficial omite.

Fuentes originales:

• Jakarta EE 11 Release Notes — jakarta.ee/release/11/
• Spring Boot 3.x Reference Documentation — docs.spring.io