La primera tabla me dejó incómodo: en mi máquina, con el workload realista del lab, Embedded GlassFish parecía ganarle a Spring Boot. Si publicaba ahí, el post tenía más punch, pero también era metodológicamente flojo. Paré la pelota y agregué lo que faltaba: JDK soportado para todos, warmup separado, ventanas medidas más largas, heap fijo, pool settings explícitos y pg_stat_statements para atribuir la base. Con eso, la conclusión cambió.
Este post no intenta decidir quién “gana para siempre”. Cuenta cómo cambió mi lectura cuando el benchmark se volvió justo. Y por qué, si hoy arranco un greenfield con un equipo que ya vive en Spring, sigo eligiendo Spring Boot; pero si estoy en una organización con Payara/Jakarta, pruebo Payara Micro; y si hay código Jakarta que busca ejecutable liviano, Embedded GlassFish entra a la conversación.
Por qué hice este experimento
Venía con una idea fácil de repetir: “Spring Boot siempre es la opción obvia”. Quería desafiarla con evidencia, no con intuición.
Me interesa Jakarta EE moderno sin nostalgia. Quería ver si hay espacio real hoy, no en 2012.
