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
