Cross-platform JRE bundle creation under threat from JEP 493
One of the most valuable capabilities introduced with the Java module system in Java 9 is its support for creating custom runtime
images with jlink. Developers can include only the modules they need, resulting in lightweight JRE bundles tailored to the
requirements of their applications. Using the --module-path option, it has even been possible to generate those runtime
images for different operating systems from a single host machine.
With Java 24, JEP 493 introduces a change that significantly impacts this workflow.
JDK vendors can now configure builds without .jmod files, as jlink can optionally extract the required resources
from the lib/modules jimage file. While this change reduces the size of the JDK by about 25%, it also removes critical support
for cross-platform linking.
The impact on deployment workflows
Cross-platform linking is essential for developers who build installation packages or runtime bundles targeting multiple operating systems.
Without .jmod files in the JDK, the --module-path option of the jlink tool can no longer be used to
link bundles for another target platform. This is because binary resources like executables and native libraries are extracted from
.jmod files. In the jmod-less mode, these resources can only be extracted from the current JDK.
This change affects tools such as install4j, the
Badass Runtime Plugin,
and Moditect, which rely on the availability of .jmod files to build
minimal, cross-platform runtime images. Their functionality is either limited or entirely blocked when .jmod files are not available.
For example, in install4j, users can select a JDK provider to build platform-specific runtime bundles directly within the project configuration:
Later in the process, the media wizard allows developers to bundle additional modules that are needed for the target platform:
Current state across JDK distributions
Adoptium has adopted JEP 493 for Eclipse Temurin in full, and its Java 24 builds no longer include .jmod files. This decision
aligns with the goals of the JEP. To their credit, the Adoptium team has been very transparent and responsive in community discussions,
and a solution to provide .jmod files as a separate download is currently being discussed.
As of Java 24.0, JDK distributions such as Azul Zulu, Amazon Corretto, and BellSoft Liberica continue to provide .jmod files in
their Java 24 builds, maintaining compatibility with existing tools and workflows. It is hoped that other JDK vendors adopting JEP 493 will also
recognize that .jmod files still need to be provided one way or another.
Proposed solution
The simplest and most practical solution is to publish .jmod files as an optional artifact alongside the standard jmod-less builds.
This would preserve support for deployment tooling without compromising the goals of JEP 493.
Maintaining .jmod builds ensures that developers have the flexibility to choose between minimized JDK distributions and
full-featured ones that support cross-platform deployment.
Community feedback matters
If your build is affected by this change, it is important to share your experience. The Adoptium issue is open, and the maintainers are actively listening to feedback.
The ability to build platform-specific runtime images remains a crucial requirement for many real-world Java projects. Let’s ensure that continues to be possible.