Hi Niclas,
The setAccessible javadoc has everything.
Alternatively, more background on the proposal in this mail:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
Rgds,Rory
On 09/12/2016 10:34, Niclas Hedhman wrote:
Rory,
do you have a pointer to where the implications of setAccessible() vs
module system is explained in detail? We are heavily "hacking"[1]
things and would like to get a handle on how we might be affected in
the long-run.
Thanks
Niclas, on behalf of Apache Zest
On Fri, Dec 9, 2016 at 6:12 PM, Rory O'Donnell
<[email protected] <mailto:[email protected]>> wrote:
Hi Paul,
JDK 9 build b148 <https://jdk9.java.net/download/
<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
<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/jdk9-dev/2016-November/005276.html>
<http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
<http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html>>
[2]
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation
<http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
