Fwd: resource location problem in JDK 9 from build 148 onward
Alan Bateman
Alan.Bateman at oracle.com
Tue Jan 17 08:30:17 UTC 2017
On 17/01/2017 00:55, Rick Hillegas wrote:
> :
>
> public class public class ResourceLocationProblem
> {
> public static void main(String... args) throws Exception
> {
> String resourceName = "/META-INF/MANIFEST.MF";
> Class dummyClass = (new Object()).getClass();
> Object is = dummyClass.getResourceAsStream(resourceName);
>
> if (is != null) { System.out.println("Resource found."); }
> else { System.out.println("Resource NOT found!"); }
> }
> }
For the example then I assume you want
ClassLoader.getSystemResourceAsStream("META-INF/MANIFEST.MF") but as
with the snippet on JDK 8, then there is no guarantee that it will find
the resource in z.jar even if it's the first JAR file on the class path
(it might locate the resource in JAR files on the boot class path or ext
directory).
As regards the Class::getResourceXXXX methods then they work exactly as
before when invoked on a class on the class path (or more generally, any
class that is not in a named module). This goes for input in both
relative and absolute input. However when invoked on a class in named
module then they locate the resource in the module. In this example then
java.lang.Object is in the java.base module. So there is a compatibility
issue for uses like the above where it looks like you are looking for
the resource in module java.base. The spec could potentially be changed
to have it fallback to the defining loader (or the system class loader
when the defining loader is null) but that would need further
consideration to see if it's the right thing to do or not.
-Alan
More information about the jigsaw-dev
mailing list