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
