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
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 <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
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 <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?
2) What is the recommended workaround?
Thanks,
-Rick
