You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@gmail.com> on 2016/12/10 21:02:44 UTC
Re: JDK 9 b148 including a refresh of the module system is available
on java.net
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
Re: JDK 9 b148 including a refresh of the module system is available
on java.net
Posted by Rick Hillegas <ri...@gmail.com>.
Thanks, Rory. I have added that advice to the issue.
On 12/12/16, 4:10 AM, Rory O'Donnell wrote:
>
> Hi Rick,
>
> It looks like a Debry test is hacking into a private field in
> java.security.Permission.
>
> You can probably workaround it temporarily by running with
> `--add-opens java.base/java.security=ALL-UNNAMED`.
>
> Rgds,Rory
>
> On 10/12/2016 21:02, Rick Hillegas wrote:
>> 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
>>
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland