Hi Rick,
<dropping derby-dev from cc list>
On 17/01/2017 10:55 AM, Rick Hillegas wrote:
Resending since the moderator rejected my initial post for want of a
subscription to jigsaw-dev.
-------- Original Message --------
Subject: resource location problem in JDK 9 from build 148 onward
Date: Mon, 16 Jan 2017 08:45:23 -0800
From: Rick Hillegas <rick.hille...@gmail.com>
To: jigsaw-dev@openjdk.java.net, "derby-...@db.apache.org"
<derby-...@db.apache.org>
Dalibor Topic suggested that I pose this question to the jigsaw-dev list:
Starting (at least) with build 148, resource location has changed in a
way which is not backward compatible with JDK 8. The following
experiment shows the behavior change:
1) Compile the following class using JDK 8 and put it in a jar file
called z.jar:
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!"); }
}
}
2) Then run the program thusly:
java -cp z.jar ResourceLocationProblem
On JDK 8, the program produces this output...
Resource found.
...while on JDK 9 build 151 the program produces this output...
Resource NOT found!
Dalibor pointed me to the following proposal, which indicates that some
significant changes have been made to resource location:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000392.html
However, I am not trying to use any jigsaw features. This test program
suggests that JDK 9 will break many legacy applications.
1) Is the observed behavior change a bug?
No. Modules enforce strong encapsulation of types and resources. As per
the link you were given:
- The `Class::getResource*` methods, when invoked upon a class defined
in a named module, only locate resources from within that module.
These methods are also caller-sensitive.
So you are using Object.class is the named java.base module to try and
find local resources in the unnamed-module, that are in z.jar. That
won't work.
2) What is the recommended workaround?
Use a Class object from the "module" that contains the resource i.e.
ResourceAllocationProblem.class in your example.
David
-----
Thanks,
-Rick
