Question on Implied readability

Alan Bateman Alan.Bateman at
Mon Nov 2 18:48:04 UTC 2015

On 02/11/2015 13:20, Ali Ebrahimi wrote:
> :
> bar1
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native
> Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0
> /
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0
> /
>          at java.lang.reflect.Method.invoke(java.base at 9.0/
>          at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0
> /
> Caused by: java.lang.IllegalAccessError: class (in module:
>   cannot access class (in module:, cannot read
>          at
>          ... 5 more
> The exception message says: cannot read Why?
> Is not two situation equivalent? (before Implied readability and after)
> This is bug?

I used the source from your mail to create a test case but I didn't 
duplicate what you were seeing. In my test then I created two layers L1 
and L2. In L1 then at 1 and com.baz are mapped to the same loader 
CL1. In L2 then at 2 and are mapped to the same loader CL2. 
The parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing 
local-first rather than parent delegation so that it loads the local 
version of module's types.

The readability is setup as expected:

         Module foo = layer2.findModule("").get();
         Module bar2 = layer2.findModule("").get();

         Module bar1 = layer1.findModule("").get();

I can't rule out a bug of course but I would need to see an outline of 
what jakeplus.minicontainer.Bootstrapper is doing so that I can see how 
the layers and class loaders are arranged.


More information about the jigsaw-dev mailing list