Spring Boot Extracted Layout vs Jib Exploded Layout
A short follow-up asking whether removing the application JAR adds a benefit after dependencies are already extracted.
Question
Does Spring Boot's extracted layout gain anything measurable by moving the application's own classes and resources out of app.jar as Jib does?
Setup
I used the same Spring Boot 4.1.1 application, OpenJDK 25.0.4, and existing Alpine VM as the related Gradle application distribution comparison.
The VM had one vCPU, 256 MiB RAM, and 512 MiB swap. Both layouts used the same JVM profile, including -Xmx80m, the same database reset, and the same loopback workload. There were three fresh starts per layout, with a 30-second survival check.
Layouts
- Spring Boot extracted:
app.jar + lib/*.jar - Jib-style exploded:
classes/ + resources/ + libs/*.jar
Results
| Layout | Median startup | Median first request | Peak RSS | Process swap |
|---|---|---|---|---|
| Spring Boot extracted | 13,880 ms | 1.829 s | 154.8 MiB | 79.1 MiB |
| Jib exploded | 13,740 ms | 2.018 s | 155.0 MiB | 79.3 MiB |
Both layouts started and served all validated requests successfully. Jib's median startup was 140 ms lower, effectively tied at this sample size. Its median first request was about 0.19 seconds higher, while RSS and process swap were similar.
What this suggests
For a simple non-container deployment, use Spring Boot's extracted layout and stop there. In this test, the Jib-style exploded layout added complexity without a measurable runtime benefit.
Jib is still useful for container image building and layering, which is a separate benefit from the runtime comparison tested here.
Evidence and limits
This was a three-run-per-layout comparison with a fixed extracted, jib order and a 30-second observation. RSS and process swap are reported in MiB here; the public CSV contains the underlying KiB values.
Experiment record Related Gradle comparison Questions and comments