On 21/01/2017 19:18, Sander Mak wrote:
I have module A trying to read a resource in module B. The resource is in
module B under 'pkg/resource.txt' and if I understood [1] correctly should be
encapsulated by default. There are no opens/exports statements in module B's
module-info. Module A tries to load 'pkg/resource.txt (after obtaining moduleB
from the boot layer):
moduleB.getResourceAsStream("pkg/resource.txt")
This returns null, which is expected behavior. Then, however, it tries to load
the same resource with a slash in front of pkg:
moduleB.getResourceAsStream("/pkg/resource.txt")
Lo and behold, an InputStream is returned, giving module A access to module B's resource from an
encapsulated package. In fact, you can prefix arbitrarily many slashes and it works. That can't be
right, can it? The resource encapsulation shouldn't be optional depending on how
Module::getResourceAsStream is called from another module, should it? I believe this is an issue in
the handling of leading (or duplicate!) slashes in jdk.internal.loader.getPackageName and the
subsequent jdk.internal.module.Checks::isPackageName that's called. This returns false for the
invocation with "/pkg/resource.txt", which misleads Module::getResourceAsStream to get
access. When you call it with "pgk//resource.txt" it will also happily provide the
InputStream
Thanks, yes, there is a bug here then the resource names has dealing or
duplicate slashes. I'm just testing some changes for this area so expect
the issues will be resolved soon (we are accumulating a number of spec
updates so it will probably go in with those).
-Alan
