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]> wrote: > > Hi Paul, > > > 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-Novembe > r/005276.html <http://mail.openjdk.java.net/pipermail/jpms-spec-experts/20 > 16-October/000430.html> > > [2] http://openjdk.java.net/projects/jigsaw/spec/issues/#Awkward > StrongEncapsulation > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
