[
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827204#comment-15827204
]
Rick Hillegas commented on DERBY-6856:
--------------------------------------
I posted to jigsaw-dev my analysis of the problem in locating derbyall. I
received the following response from David Holmes:
{noformat}
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 <[email protected]>
> To: [email protected], "[email protected]"
> <[email protected]>
>
>
>
> 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
>
{noformat}
The suggested workaround works. The following code performs identically on JDK
8 and 9:
{noformat}
public class ResourceLocationProblem
{
public static void main(String... args) throws Exception
{
String resourceName = "/META-INF/MANIFEST.MF";
//Class dummyClass = (new Object()).getClass();
Class dummyClass = ResourceLocationProblem.class;
Object is = dummyClass.getResourceAsStream(resourceName);
if (is != null) { System.out.println("Resource found."); }
else { System.out.println("Resource NOT found!"); }
}
}
{noformat}
> Make it possible to build Derby using JDK 9
> -------------------------------------------
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.12.1.1
> Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff,
> derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff,
> derby-6856-03-aa-autoboxingDeprecationWarnings.diff,
> derby-6856-03-ab-autoboxingDeprecationWarnings.diff,
> derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff,
> derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff,
> derby-6856-05-ac-roundingMode-Class.newInstance.diff,
> derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff,
> derby-6856-05-ag-roundingMode-Class.newInstance.diff,
> derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff,
> derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff,
> derby-6856-10-aa-disable-permissions-subverting-test.diff,
> derby-6856-XX-ab-base.diff, derby-6856-XX-ac-base.diff, PTest.java,
> ptestScript
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool
> which we use so that old JVMs can compile Derby and so that Derby can be
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the
> development cycle of Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
