db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@gmail.com>
Subject Re: JDK 9 b148 including a refresh of the module system is available on java.net
Date Sat, 10 Dec 2016 21:02:44 GMT
Hi Rory,

My experience compiling and testing Derby with jdk 9 build 148 is 
recorded in the 2016-12-10 comment on 
https://issues.apache.org/jira/browse/DERBY-6856. I am copying that 
comment into this message:

I compiled and tested Derby with build 148 of jdk 9. Compilation 
succeeded. The errors which I saw on build 144 have gone away.

However, I see the following new problems when I run the tests under jdk 
9. These problems surface regardless of whether I compile Derby with jdk 
8 or jdk 9:

The derbyall suite was not found when I ran the usual command:

   java -Dverbose=true 
org.apache.derbyTesting.functionTests.harness.RunSuite derbyall

And the junit tests had a module-related error:

There was 1 error:
1) 
testSerialization(org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest)java.lang.reflect.InaccessibleObjectException:

Unable to make field private java.lang.String 
java.security.Permission.name accessible: module java.base does not 
"opens java.security" to unnamed module @6d1d4d7
     at 
java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:427)
     at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:201)
     at 
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
     at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
     at 
org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest.setField(SystemPrivilegesPermissionTest.java:1039)
     at 
org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest.createDBPermNoCheck(SystemPrivilegesPermissionTest.java:998)
     at 
org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest.testDatabasePermissionSerialization(SystemPrivilegesPermissionTest.java:826)
     at 
org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest.testSerialization(SystemPrivilegesPermissionTest.java:784)
     at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
     at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
     at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
     at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
     at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
     at junit.extensions.TestSetup.run(TestSetup.java:25)

FAILURES!!!
Tests run: 14023,  Failures: 0,  Errors: 1

I am not inclined to spend the considerable time which I expended 
scripting the problems with build 144. I am cautiously hopeful that 
these errors will not recur in the next build of JDK 9.

Thanks,
-Rick


On 12/9/16, 2:04 AM, Rory O'Donnell wrote:
>
>
> Hi Rick,
>
>
> JDK 9 build b148 <https://jdk9.java.net/download/> includes an 
> important Refresh of the module system [1] , summary of  changes are 
> listed here <http://download.java.net/java/jdk9/changes/jdk-9+148.html>.
>
> *This refresh includes a disruptive change that is important to 
> understand.
>
> *For those that have been trying out modules with regular JDK 9 builds 
> then be aware that `requires public` changes to `requires transitive`. 
> In addition, the binary representation of the module declaration 
> (module-info.class) has changed so that you need to recompile any 
> modules that were compiled with previous JDK 9 builds.
>
> As things stand today in JDK 9 then you use setAccessible to break 
> into non-public elements of any type in exported packages. However, it 
> cannot be used to break into any type in non-exported package. The 
> current specified behavior was a compromise for the initial 
> integration of the module system. It is of course not very 
> satisfactory, hence the #AwkwardStrongEncapsulation issue [2] on the 
> JSR 376 issues list. With the updated proposal in the JSR, this 
> refresh changes setAccessible further so that it cannot be used to 
> break into non-public types, or non-public elements of public types, 
> in exported packages. Code that uses setAccessible to hack into the 
> private constructor of java.lang.invoke.MethodHandles.Lookup will be 
> disappointed for example.
>
> This change will expose hacks in many existing libraries and tools. As 
> a workaround then a new command line option `--add-opens` can be used 
> to open specific packages for "deep reflection". For example, a really 
> popular build tool fails with this refresh because it uses 
> setAccessible + core reflection to hack into a private field of an 
> unmodifiable collection so that it can mutate it, facepalm! This code 
> will continue to work as before when run with `--add-opens 
> java.base/java.util=ALL-UNNAMED` to open the package java.util in 
> module java.base to "all unnamed modules" (think class path).
>
> *Any help reporting issues to popular tools and libraries would be 
> appreciated. *
>
> A debugging aid that is useful to identify issues is to run with 
> -Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when 
> setAccessible fails, this is particularly useful when code swallows 
> exceptions without any logging.
>
>
> Rgds,Rory
>
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html 
> <http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html>
> [2] 
> http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland


Mime
View raw message