Write Once, Run Anywhere? Building Perfect Docker Images for Java Apps
summary
Compares three concrete build paths: classic Dockerfile/buildx, Spring Buildpacks (slow but configurable), and Jib (creates image without Docker daemon); measures show a Mac M1 run uses emulation and inflates Java startup from ~3s to ~30s; most image bytes are JVM+OS (~80%) so a fat jar creates one huge invalidated layer while multi-layered images speed push/pull and startup; tooling demonstrated: Dive, container-diff, lazydocker, New Relic; recommends setting container memory/CPU limits and JVM memory flags and building multi-arch images when needed.
AI-written summary · about
chapters (10)
- 0:00Docker for Java apps
- 5:26Java’s ‘Write Once Run Anywhere’
- 13:19How Docker images work
- 17:58Three ways to build Java images
- 25:13Efficient Docker image design
- 30:55Multi-platform Java images
- 34:07Java runtime in Docker
- 37:17Docker Desktop alternatives
- 38:20Optimizing Docker workflows
- 44:29Q&A
related talks
46mDockerfiles, Buildpacks, Jib and more, best way to run Java code in Containers?
34mDefence Against the Docker Arts
31mFast and Distroless Java in Containers: the Recipe!
01h 15mEvaluation of OSS Options to Build Container Images
54mHowto: Options Galore to Get from Source Code to Container
51mJava applications containerized and deployed, make your buildpack edition
50mHowto: Options Galore to Get from Source Code to Container
58mOptions Galore to Get from Source Code to Container