Yes! It broke some Byteman tests in Search already; might simply need
some different JVM switches, but I'll look at this next week.
Pasting Rory O'Donnell's email:
========================
JDK 9 build b148 includes an important Refresh of the module system
[1] , summary of changes are listed here .
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
[2]
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsu...
On 9 December 2016 at 14:02, Steve Ebersole <steve(a)hibernate.org> wrote:
Is this the build with the "disruptive change"?
On Fri, Dec 9, 2016, 7:43 AM Davide D'Alto <davide(a)hibernate.org> wrote:
Hi,
I just wanted to inform that I've updated the JDK 9 version on CI to build
148.
Let me know if there are problems.
Cheers,
Davide
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev