Alan, please correct me if wrong, but there is no enforced correlation
between the module name and the jar name it's packaged in, right? The name
is officially taken from the module-info.class? If so, I'd like to make a
suggestion. One thing that's been extremely useful to me with JBoss is the
ability to link back to the JAR path in the stack trace. Is there any
chance you would consider expanding the stack trace to something like this:
bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0
[c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod)
Paul
Cheers,
Paul
On Mon, Nov 2, 2015 at 12:48 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:
> 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@9.0
>> /Native
>> Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0
>> /NativeMethodAccessorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0
>> /DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(java.base@9.0
>> /Method.java:531)
>> at jakeplus.minicontainer.Bootstrapper.main(java.base@9.0
>> /Bootstrapper.java:67)
>> Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
>> com.foo)
>> cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
>> read
>> com.bar
>> at com.foo.Main.main(com.foo/Main.java:12)
>> ... 5 more
>>
>> The exception message says: com.foo cannot read com.bar. 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 com.bar@1 and com.baz are mapped to the same loader CL1.
> In L2 then com.bar@2 and com.foo 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
> com.bar's types.
>
> The readability is setup as expected:
>
> Module foo = layer2.findModule("com.foo").get();
> Module bar2 = layer2.findModule("com.bar").get();
> assertTrue(foo.canRead(bar2));
>
> Module bar1 = layer1.findModule("com.bar").get();
> assertFalse(foo.canRead(bar1))
>
> 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.
>
> -Alan.
>
