Packaging, Build Plugins & DevTools

With Maven run mvn spring-boot:run; with Gradle run ./gradlew bootRun. Both compile and start your @SpringBootApplication main class in dev. The plugins also build an executable jar containing all dependencies so java -jar just works.

spring-boot-devtools is an optional dev-only dependency. It automatically restarts your app when class files change, refreshes the browser via LiveReload, applies developer-friendly property defaults (like disabling template caching), and is left out of production jars.

A single runnable jar containing your compiled classes plus all dependency jars. You run it with java -jar app.jar. Spring puts your code in BOOT-INF/classes and dependency jars in BOOT-INF/lib.

Set the image name (imageName in Gradle, <image><name> in Maven, or --imageName= / -Dspring-boot.build-image.imageName=). To push, enable publish (publish = true / <publish>true</publish>) and provide registry credentials via docker.publishRegistry.

repackage takes the plain jar Maven already built and rewrites it into an executable 'fat' jar: dependencies nested under BOOT-INF/lib, your classes under BOOT-INF/classes, plus a launcher in the manifest. Gradle's bootJar task builds the same executable jar directly.

Three steps: (1) extract the fat jar to a folder, (2) do a training run with -XX:ArchiveClassesAtExit=app.jsa and -Dspring.context.exit=onRefresh to produce the archive, (3) run normally with -XX:SharedArchiveFile=app.jsa.

You declare DevTools as developmentOnly (Gradle) or optional (Maven) so it isn't packaged into the production jar. As a safety net, DevTools also disables itself automatically when it detects the app was started from a fully packaged jar rather than exploded classes.

JarLauncher is Spring Boot's bootstrap class named as Main-Class in the manifest. The JVM runs it first; it builds a classloader that can read the nested jars in BOOT-INF/lib, then calls your app's Start-Class main method.

In order: dependencies, spring-boot-loader, snapshot-dependencies, application. They go from least-likely-to-change to most-likely-to-change so Docker keeps the stable ones cached and only rebuilds the top application layer.

java -Djarmode=layertools -jar app.jar extract reads layers.idx and writes one folder per layer. In a builder Docker stage you run it, then COPY each folder into the final image separately (stable first) and start with JarLauncher.

CDS saves the classes the JVM loads into a shared archive file. On the next startup the JVM memory-maps that archive instead of reading and parsing each class from the jar, so class loading is faster and startup time drops.

A layered jar splits a Spring Boot fat jar into groups (layers) that change at different rates. In a Dockerfile you copy each layer separately so slow-changing dependency layers stay cached and only your fast-changing code is rebuilt.

The .jsa is the shared archive file holding pre-parsed class metadata. -XX:ArchiveClassesAtExit writes that archive when the training JVM exits. -XX:SharedArchiveFile points a later JVM at the archive to memory-map it at startup. One writes, one reads.

LiveReload is an embedded server (port 35729) that tells a browser extension to refresh the page when a resource changes. Property defaults are dev-friendly overrides DevTools applies automatically — mainly disabling template/resource caching — so your edits show up immediately.

Main-Class is what the JVM runs for java -jar — Spring sets it to JarLauncher. Start-Class is your real @SpringBootApplication main. JarLauncher first fixes the classpath for nested jars, then calls Start-Class.

Layering is on by default since Spring Boot 2.4 via the Gradle/Maven Boot plugin. You can toggle it in the plugin's layered config. To inspect, run java -Djarmode=layertools -jar app.jar list, or unzip and open BOOT-INF/layers.idx.

Override the builder (e.g. builder = "paketobuildpacks/builder-jammy-base") and/or runImage. Pass build-time settings to the buildpacks via environment map entries, e.g. BP_JVM_VERSION=21 to pick the JRE version.

The buildpack explodes the executable jar into Spring Boot's layered structure (dependencies, loader, snapshot deps, application) so changing only your code rebuilds just the top layer. A native build (BP_NATIVE_IMAGE=true) instead AOT-compiles to a single native executable — tiny, fast-starting, no JVM.

By default the executable jar replaces the plain jar under the same coordinates. Setting a classifier (e.g. exec) gives the executable jar a suffixed name so both the plain library jar and the executable jar are kept and can be published side by side.

In the spring-boot-maven-plugin configuration use <excludes> (by groupId/artifactId), <excludeGroupIds>, or <excludeArtifactIds> so those jars aren't nested into BOOT-INF/lib. You do this when a dependency is provided by the runtime environment or shouldn't be shipped.

The archive is tied to the exact classpath and JDK it was built with. If either changes, the JVM detects a mismatch, ignores the archive, and falls back to normal class loading (no crash). Verify with -Xshare:on (fails if unusable) or -Xlog:cds logging.

DevTools uses two classloaders: a base classloader for unchanging library jars and a restart classloader for your own code. On a file change it discards and rebuilds only the restart classloader and the application context, so libraries stay loaded and startup is much faster than a cold JVM start.

A shaded jar unzips every dependency and merges all classes into one flat jar, which can overwrite duplicate resources. Spring Boot keeps each dependency as a whole nested jar under BOOT-INF/lib, preserving resources and library identity.

Use CDS when you want cheaper, faster startup while keeping an ordinary JVM (full reflection, easy debugging, no special build). It gives a moderate startup cut with almost no risk and stacks with AOT; native images give bigger gains but cost far more build/complexity.

Buildpacks give maintenance-free, secure, well-layered images and automatic base-image patching, at the cost of control. Dockerfiles give full control but you own security/layering. For reproducibility, pin the builder/run images by digest, control the JVM version, manage registry creds as secrets, and scan the output.

bootJar builds the executable fat jar; the standard jar task builds a plain library jar (given a -plain classifier by default since Boot 2.5). Layered jars split the fat jar into ordered layers (dependencies, app code) so Docker can cache stable layers and rebuild only what changed.

Never enable remote DevTools against production — it can execute code on the server. Also watch for cross-restart ClassCastExceptions from the two-classloader model, lost in-memory state on each restart, and exploded-run deployments where DevTools may not self-disable. Keep it strictly developmentOnly.

Split the fat jar into Docker layers (dependencies vs app code) so rarely-changing layers stay cached, and optionally run the exploded jar (extracted BOOT-INF) with JarLauncher to reduce nested-jar classloading overhead and speed startup.

Use the layertools Dockerfile when you need full control over the base image, JVM flags, or non-standard layout. Use buildpacks (bootBuildImage) for zero-Dockerfile, best-practice images. Layering speeds up builds/pushes; CDS/AOT speed up app startup — they are complementary, not alternatives.