Thanks for the quick fix! When will a new build available? I need this fix
for my Devoxx presentation Tuesday, or come up with a different plan to
work around it.
Paul
On Sat, Mar 18, 2017 at 1:09 AM, Alan Bateman <alan.bate...@oracle.com>
wrote:
> 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
>
>
