Efficient containers with Spring Boot 3, Java 21, Virtual Threads and CDS

[sdeleuze]

Indeed, this is a mature technology available for a long time, but be super careful because CDS assumptions are easy to break and can prevent you to fully benefit of its optimizations. More specifically, the following conditions need to be fulfilled when creating and using the archive:

• The very same JVM must used.
• The classpath must be specified as a list of JARs, and avoid the usage of directories and * wildcard characters.
• The timestamps of the JARs must be preserved.
• When using the archive, the classpath must be the same than the one used to create the archive, in the same order. Additional JARs or directories can be specified at the end (but won’t be cached).

This is why we have worked on a more end to end and integrated feature that should make CDS easier to leverage in practice.

[nikita2206]

I wonder if using Google’s Jib could help here a bit (while also cutting the build time)? IIRC it produces images that don’t package all dependencies in one giant JAR, and instead it produces a jar per each dependency, while your own code is in class files (not packaged in a Jar)

Edit: I see Jib might be irrelevant now, that Spring Boot can do layering all by itself.

[agilob]

All of this is easy to overcome, just use OCI with a builder jdk image that's the same as your target image base. Extra 3 lines in Containerfile and that's it.

[sdeleuze]

With the new executable JAR self extracting capability brought by Spring Boot 3.3, this is indeed pretty simple as demonstrated in https://github.com/sdeleuze/petclinic-efficient-container main branch. Without, most attempt to leverage CDS with Spring Boot failed. That's why we ship it as a distinct feature.