db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9
Date Wed, 18 Jan 2017 01:27:26 GMT

    [ 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 <rick.hillegas@gmail.com>
> To:     jigsaw-dev@openjdk.java.net, "derby-dev@db.apache.org"
> <derby-dev@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
>
{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)

Mime
View raw message