Java Container Mastery: Optimizing Images Across Build Tools
summary
Compares plain Dockerfiles, multi-stage Dockerfile builds, Cloud-Native Buildpacks (pack/Paketo), Google's Jib, and custom runtimes via jlink/jdeps, measuring build speed, image size, pipeline robustness, JVM memory config, and security. Demonstrates layered extraction for Spring Boot to reduce rebuilds, shows images from ~300 MB down to 93–185 MB when using jlink, notes buildpacks auto-rebase bases and emit SBOMs, and says daemonless tools (Jib/pack) speed CI while preserving reproducible, cacheable layers.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker background
- 1:53Why optimize Java container images
- 3:58Container basics and Docker fundamentals
- 7:08Dockerfile evolution and multi-stage builds
- 11:20Image optimization criteria and trade-offs
- 14:59JLink and JDeps for custom JREs
- 21:21Introduction to Cloud Native Buildpacks
- 24:12Chip as a Maven/Gradle plugin
- 30:29Comparing Dockerfiles, Chip, and Buildpacks
- 32:34Frameworks and native images
- 35:46Security and supply chain standards
- 38:53Demo and image size comparison
- 48:03Q&A and closing remarks
related talks
49mDockerfiles, Jib ..., what's the best way to run your Java code in Containers?
46mDockerfiles, Buildpacks, Jib and more, best way to run Java code in Containers?
51mJava applications containerized and deployed, make your buildpack edition
32mDockerfile vs Jib vs Pack vs Native Image: Which Is the Best Image Build Method?
43mBuilding containers without DockerFile
25mCommit to Excellence - Java in Containers
40mJdeps, Jlink and Layers: Slim Down Your Java Docker Images
45mBuilding & Managing Container Images at Scale with Cloud Native Buildpacks