On 13/08/2026 12:31, Rafael Winterhalter wrote:
Hello,
I wonder if this is an undocumented limitation, or an oversight. When
patching a module with a jar, and when this jar is a multi-version jar,
these class files are not considered during the patch application.
From java.base/jdk/internal/module/ModulePatcher.java, I find the comment:
JAR file - do not open as a multi-release JAR as this is not supported by
the boot class loader
Thereafter, the constructor that does not consider the JVM's version is
used as the comment indicates.
However, this rule is also applied when patching modules on the module
path, which are not loaded by the boot loader but the system loader.
Maybe patching was planned to be used with boot modules, but at least for
me this came surprising. The surprising behaviour seems consistent with
regards to java and javac.
Thanks for any information on this corner-case.
Two points on Multi-release JARs that I think you know already:
1. MR- JARs are not supported with -Xbootclasspath/a
2. Modular MR-JARs are supported on the module path
JEP 238 has more on both of these topics.
--patch-module is the propeller head option for patching any module in
the boot layer. It's primary motivation is testing and debugging with
JEP 261 discouraging usages beyond that. It's the module replacement for
what was -Xbootclasspath/p so really important for testing the JDK. It's
also important for things like that the Maven compiler and surefire
plugin that compile/run tests "as if" they are in the same run-time
package as the module code they are testing.
--patch-module can be used to patch the content of a module packaged in
a modular MR-JAR on the module path. This includes modular MR-JARs that
become automatic modules.
--patch-module does not define/support a means to package multiple
patches for different JDK releases into a single JAR file. This is not
an oversight, instead it's not something we wanted to get into in JDK 9
as it adds another dimension of complexity.
I assume the context for the question is the scenario you had yesterday
where a library is being coerced into having a stable module name. A
stand in JAR file with a module-info.class is deployed, and
--patch-module is used to add the module content from the original JAR
file. If the original library is a MR-JAR then it can't reliably be
used, the versions section will not be used.
Rather than adding more complexity then this seems like a case where the
library author needs to cooperate.
-Alan
