IllegalAccessError with --patch-module

[Johannes Kuhn]

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.Bateman at 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
>>