Fwd: resource location problem in JDK 9 from build 148 onward
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
To: jigsaw-dev@openjdk.java.net, "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?
2) What is the recommended workaround?
Thanks,
-Rick
Re: Fwd: resource location problem in JDK 9 from build 148 onward
Hi Rick,
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
To: jigsaw-dev@openjdk.java.net, "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
Re: Fwd: resource location problem in JDK 9 from build 148 onward
Typo: ResourceAllocationProblem.class -> ResourceLocationProblem.class
David
On 17/01/2017 11:15 AM, David Holmes wrote:
Hi Rick,
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
To: jigsaw-dev@openjdk.java.net, "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
Re: Fwd: resource location problem in JDK 9 from build 148 onward
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::getResource 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
Re: Fwd: resource location problem in JDK 9 from build 148 onward
Thanks, David and Alan. The suggested workaround works for me. I will
mouse your response into the commentary on
https://issues.apache.org/jira/browse/DERBY-6856, where I have been
collecting all of the issues I've encountered when building and testing
Apache Derby with JDK 9.
I strongly recommend a GA release note about this topic if the
backward-incompatibility won't be ameliorated.
Thanks,
-Rick
On 1/16/17, 5:15 PM, David Holmes wrote:
Hi Rick,
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
To: jigsaw-dev@openjdk.java.net, "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
Re: Fwd: resource location problem in JDK 9 from build 148 onward
On 18/01/2017 01:21, Rick Hillegas wrote: Thanks, David and Alan. The suggested workaround works for me. I will mouse your response into the commentary on https://issues.apache.org/jira/browse/DERBY-6856, where I have been collecting all of the issues I've encountered when building and testing Apache Derby with JDK 9. I strongly recommend a GA release note about this topic if the backward-incompatibility won't be ameliorated. The "Risks and Assumptions" section in JEP 261 will be refreshed soon so that it has an up to date list of the compatibility issues that relate to the changes that we are doing here. They will eventually show up in release notes and migration documentation. Thanks for the link to the Derby issue tracking your migration efforts. From a quick read then the only other issue that seems to be relevant to what we are doing here is the test that was hacking into a field of java.security.Permission. As regards the test using Object.class to locate "/org/apache/derbyTesting/functionTests/suites/derbyall.properties" then it's an odd way to locate a resource and not clear why it didn't use ClassLoader.getSystemResourceAsStream originally. Anyway, as I said, we'll need to see if using types in modules to locate a resource on the class path make sense or not. -Alan
Re: Fwd: resource location problem in JDK 9 from build 148 onward
On 1/18/17, 2:14 AM, Alan Bateman wrote: On 18/01/2017 01:21, Rick Hillegas wrote: Thanks, David and Alan. The suggested workaround works for me. I will mouse your response into the commentary on https://issues.apache.org/jira/browse/DERBY-6856, where I have been collecting all of the issues I've encountered when building and testing Apache Derby with JDK 9. I strongly recommend a GA release note about this topic if the backward-incompatibility won't be ameliorated. The "Risks and Assumptions" section in JEP 261 will be refreshed soon so that it has an up to date list of the compatibility issues that relate to the changes that we are doing here. They will eventually show up in release notes and migration documentation. Thanks again, Alan. Thanks for the link to the Derby issue tracking your migration efforts. From a quick read then the only other issue that seems to be relevant to what we are doing here is the test that was hacking into a field of java.security.Permission. As regards the test using Object.class to locate "/org/apache/derbyTesting/functionTests/suites/derbyall.properties" then it's an odd way to locate a resource and not clear why it didn't use ClassLoader.getSystemResourceAsStream originally. Anyway, as I said, we'll need to see if using types in modules to locate a resource on the class path make sense or not. I don't know why the original author coded it that way. It's a very old piece of code from the last millennium, something that just worked and therefore wasn't touched for almost two decades. Cheers, -Rick -Alan
