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