Indeed a bug.
Happens under the following conditions:
* Patched module is an automatic module
* Patch adds one or more additional packages to the module.
Cause are the following lines:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/module/ModulePatcher.java#L154
This creates a module builder without strict mode.
The following lines won't copy the original dependencies over if it is
an automatic module.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L2130
The dependency to java.base is not added - because the module builder is
not strict.
The simple fix of adding a requires(... "java.base" ...) doesn't work -
because automatic modules can't require anything:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L1554
Proposed fix:
* Change requires to not check if it is an automatic module if the
builder is not strict.
* Move the copying of the requires out of the if.
- Johannes
On 06-Jan-21 22:47, Thiago Henrique Hupner wrote:
This is getting very confusing.
If you use any jar as an automatic module in the "--module-path" (-p) and
add the main class in another jar (in this example jar-b.jar), patch both
and the error happens.
The main class is literally just an empty main method [1].
The error happens even if we use an empty jar.
Running:
/jvms/jdk-15/bin/java -p /tmp/activation.jar --show-module-resolution
--patch-module=activation=target/jar-b.jar -m activation/com.foo.Main
root activation file:///tmp/activation.jar automatic
Error: Unable to load main class com.foo.Main in module activation
java.lang.IllegalAccessError: superclass access check failed: class
com.foo.Main (in module activation) cannot access class java.lang.Object
(in module java.base) because module java.base does not export java.lang to
module activation
However, it works if we --add-modules java.base
java -p /tmp/activation.jar --add-modules=java.base
--show-module-resolution --patch-module=activation=target/jar-b.jar -m
activation/com.foo.Main
root activation file:///tmp/activation.jar automatic
root java.base jrt:/java.base
java.base binds java.logging jrt:/java.logging
java.base binds java.management jrt:/java.management
java.base binds jdk.security.auth jrt:/jdk.security.auth
java.base binds jdk.charsets jrt:/jdk.charsets
java.base binds jdk.zipfs jrt:/jdk.zipfs
java.base binds jdk.localedata jrt:/jdk.localedata
[...]
Looks like if the automatic module is patched it loses the requires
java.base
java -p /tmp/activation.jar --add-modules=java.base
--describe-module=activation --patch-module=activation=target/jar-b.jar
WARNING: Unknown module: activation specified to --patch-module
activation file:///tmp/activation.jar automatic
contains com.foo
contains com.sun.activation.registries
contains com.sun.activation.viewers
contains javax.activation
java -p /tmp/activation.jar --add-modules=java.base
--describe-module=activation
activation file:///tmp/activation.jar automatic
requires java.base mandated
contains com.sun.activation.registries
contains com.sun.activation.viewers
contains javax.activation
[1]
package com.foo;
public class Main {
public static void main(String[] args) throws Exception{
}
}
Em qua., 6 de jan. de 2021 às 17:26, Alan Bateman <alan.bate...@oracle.com>
escreveu:
On 06/01/2021 19:57, Thiago Henrique Hupner wrote:
Sorry, they are automatic modules.
I'll create a test case.
Also if you can include the output with --show-module-resolution then it
might help track this down quickly (running without any explicit modules
on the module path is, on the surface, a bit unusual but I wouldn't
expect any issues).
-Alan
