Yes, it is. I went back to trying to name the jar accordingly, but it's a bit awkward, and the command line is under better control. Of course, if everybody named their jars in the manifest, this was to be preferred, but that is out of my hands.
Thanks for the pointers so far. Best regards, Rafael Am Do., 13. Aug. 2026 um 16:27 Uhr schrieb Alan Bateman < [email protected]>: > 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 > > >
