polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: JDK 9 b148 including a refresh of the module system is available on java.net
Date Fri, 09 Dec 2016 10:34:11 GMT
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.

Niclas, on behalf of Apache Zest

On Fri, Dec 9, 2016 at 6:12 PM, Rory O'Donnell <rory.odonnell@oracle.com>

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message