JAR searched on the classpath instead of the module path in Build #156

[Alan Bateman]

On 18/03/2017 07:09, Paul Bakker wrote:

> Following up on my earlier message, I think I found a bug in
> jdk.internal.loader.BuiltinClassLoader.
> When a resource is loaded from a package that does not contain classes in
> an automatic module, the loading works fine. When the resource is loaded
> from a package that does contain classes, the loading fails.
>
> In jdk.internal.loader.BuiltinClassLoader on line 261 the following happens:
>
>    public URL findResource(String name) {
>          String pn = Resources.toPackageName(name);
>          LoadedModule module = packageToModule.get(pn);
>          if (module != null) {
>
> 1) When no classes exist in the package (but other resources do), the
> module is null
> 2) When classes do exist in the package, the module has a value.
Right, the packages that an automatic module contains are the packages 
that contain class files. Since this is an automatic module then there 
should be no encapsulation (same thing for open modules). The bug seems 
to be a recent regression where non-class resources in packages are now 
encapsulated. We need more tests here. I'll push a fix for this today to 
jake so that it goes into JDK 9 with the next integration (more on this 
soon as JDK 9 is in RDP2). Thanks for running into this.

In passing, if hibernate.core does eventually migrate to a module then 
using LocalSchemaLocator.class.getClassLoader().getResource(...) to 
local non-class resources in its own JAR file should change to 
LocalSchemaLocator.class.getResource(...). Then it will be guaranteed to 
locate its own resource and will also allow it to encapsulate it so that 
it is not located by others.

-Alan