Spring Boot: por que los layered jar aceleran el despliegue en Docker
El formato tradicional empaqueta todo junto, obligando a resubir megas de librerias inmutables en cada rebuild. El layered jar soluciona esto explotando el caching de capas.
Spring Boot lleva anos vendiendo la comodidad del "java -jar": un solo archivo, un servidor embebido y adios a las configuraciones de classpath manuales. Detras de esa simplicidad se oculta una decision de arquitectura que define como se despliega una aplicacion: el fat jar tradicional frente al layered jar.
El problema tecnico es claro. El classloader estandar de Java no puede leer un archivo JAR dentro de otro JAR. Para que funcione el archivo unico, Spring Boot utiliza un plugin de empaquetado que reconstruye el artefacto. No mezcla las clases (lo cual provocaria colisiones), sino que coloca las dependencias intactas dentro de BOOT-INF/lib y añade un JarLauncher a la raiz. Este launcher instala un classloader personalizado capaz de navegar por esa estructura anidada antes de ejecutar la aplicacion real.
Funciona perfectamente, pero sufre en entornos de contenedores. Una imagen Docker se construye por capas para aprovechar el caching. Si usas un fat jar convencional y copias el archivo en el Dockerfile, formas una sola capa. Al cambiar una sola linea de codigo, el hash del JAR cambia por completo. Docker invalida la cache y vuelve a subir los megabytes de dependencias (Jackson, Tomcat, Log4j) que no han variado en meses. Es ineficiente al maximo.
La solucion es el layered jar, disponible desde Spring Boot 2.3. Este formato incluye un indice (BOOT-INF/layers.idx) que ordena el contenido por probabilidad de cambio. Las librerias de terceros, que rara vez se modifican, van a una capa; la aplicacion, que cambia constantemente, a otra.
Al montar el contenedor, Docker ve capas distintas. Si solo tocas tu codigo, solo subes esa capa pequena. Las dependencias pesadas se obtienen de la cache local del registro o del nodo. La diferencia en tiempo de despliegue y ancho de banda es notable en pipelines continuos.
DevTools y el desarrollo local
Mientras los layered jars optimizan el despliegue, Spring Boot DevTools ataca la latencia en desarrollo. Activa el "restart" automatico, reiniciando la JVM rapidamente cuando detecta cambios en la clasepath, evitando el ciclo lento de detener, compilar y ejecutar. Tambien precalienta plantillas Thymeleaf y desactiva caches irrelevantes para debugging.
La combinacion de layered jars para produccion y DevTools para desarrollo cubre ambos extremos del ciclo de vida. El fat jar solitario ya no tiene excusa en arquitecturas modernas donde la velocidad de deploy importa.
