All 15 Java Platform Module System (JPMS) questions
More in Java Platform Module System (JPMS)
What are the practical trade-offs and adoption challenges that have led many real-world Java projects to NOT fully adopt JPMS modularization even years after its introduction, despite its stated benefits? What is a qualified export (exports package to specificModule), and when would you use it instead of a plain, unqualified export? What is the difference between 'requires' and 'requires transitive', and how does transitive dependency propagation work in the module system? How does the 'unnamed module' work, and how does JPMS maintain backward compatibility with the vast ecosystem of pre-existing JARs that were never designed with modules in mind? How would you diagnose and resolve common JPMS migration errors, such as 'package is not visible' or a split package conflict, when modularizing an existing large application? How does JPMS's strong encapsulation interact with reflection-heavy frameworks and libraries that predate the module system, and what specific JVM flags (like --add-opens) exist as an escape hatch for cases where proper module declarations aren't feasible? How would you use the 'requires static' directive to declare an optional, compile-time-only dependency that isn't required to be present at runtime?
Advertisement
Back to results for “Performance”
Java › Java Platform Module System (JPMS)

How would you use jlink to create a custom, minimal Java runtime image containing only the specific modules an application actually needs, and what deployment benefits does this provide?

Advanced

Answer

jlink (a JDK tool) assembles a custom runtime image by analyzing an application's module dependencies and including ONLY those specific JDK modules (plus the application's own modules) actually required, rather than bundling the entire JDK -- this produces a significantly smaller, self-contained deployable runtime image (potentially reducing the deployed footprint from hundreds of megabytes for a full JDK down to a much smaller custom image containing just what's genuinely needed), particularly valuable for containerized deployments (smaller container images, faster pull/startup times) or resource-constrained environments, and since the custom image is entirely self-contained, it doesn't even require a separately-installed JDK/JRE on the target deployment machine at all.
# Create a custom runtime image containing only the required modules
jlink --module-path $JAVA_HOME/jmods:mymodules \
      --add-modules com.example.myapp \
      --output custom-runtime \
      --strip-debug --compress=2 --no-header-files --no-man-pages

# Run the application using ONLY the custom, minimal runtime image -- no separate JDK install needed
./custom-runtime/bin/java --module com.example.myapp/com.example.myapp.Main
Real-world example A containerized microservice reduces its Docker image size dramatically by using jlink to bundle only the specific JDK modules its code actually depends on (like java.base and java.sql, but not, for example, java.desktop or other unused modules), resulting in significantly faster image pulls and container startup times compared to shipping alongside a full, general-purpose JDK installation.

Common follow-ups: How does jlink determine exactly which JDK modules an application transitively depends on?;What are the deployment and maintenance trade-offs of a custom jlink-produced runtime image versus relying on a standard, widely-available JDK installation?

Deploy Checklist;Diagnostics & Performance
All 15 Java Platform Module System (JPMS) questions