Summary

The module descriptors used when --release N is specified will specify module version N.

Problem

Currently, when compiling with --release N on JDK O, the module descriptors used may either a) use no module version (for N < O); or b) use the current JDK's module version (for N == O). In the latter case, the version may be e.g. in the form of 21 or 21.0.1, etc., depending on the update release. This is problematic when using JDK to produce reproducible builds for modularized project, as these versions are compiled into the project's module descriptors, and differ across JDK versions. Therefore, the user's module descriptors are not reproducible across JDK versions or even JDK update versions.

For example, consider compiling:

module m {}

with --release 21. This will encode a version of the java.base module in the resulting module-info.class, and the encoded version will differ:

When -source 21 is used instead of --release 21, the recorded version will be (because the compilation runs against the runtime classfiles, not against the historical data):

Solution

Always include a module version in module descriptors used when compiling with --release.

Following the example above, the recorded versions will be:

When using -source 21 instead of --release 21, the recorded versions will remain as before (because the compilation runs against the runtime classfiles, not against the historical data):

Specification

When compiling with --release N, the module descriptors will always specify N as a version. For pre-release builds, the version will be N-${pre-release-version}.