On 11/09/2015 08:47, Cédric Champeau wrote:
For what it's worth, the issue that triggered this conversation is the
one reported by Uwe. For Groovy we have a chicken and egg problem for
testing, because this change breaks Groovy, and Groovy uses Gradle to
build. Since Gradle itself uses Groovy, we have no compatible build
tool to test the fix... So it's very problematic. Also the build that
we set up failed with:
[23:53:08]W:[Gradle failure report] Caused by: java.lang.VerifyError:
class com.google.common.reflect.Element overrides final method
java.lang.reflect.AccessibleObject.setAccessible(Z)V
[23:53:08]W:[Gradle failure report] at
java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
[23:53:08]W:[Gradle failure report] at
java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)
[23:53:08]W:[Gradle failure report] at
java.security.SecureClassLoader.defineClass(java.base@9.0/SecureClassLoader.java:152)
Which indicates the change to setAccessible also broke Guava, which is
used by Gradle. So it's going to be very complicated to even try to
fix the issue in those conditions. Anyway, it doesn't seem a good idea
to introduce a new exception type. Even if it is semantically a bit
problematic, wouldn't make ReflectiveOperationException a subclass of
SecurityException an option?
The right exception for this case might need more consideration but I
assume the underlying issue must be a failed attempt to get access to a
member of a type in a non-exported package.
Is there any way to run this with -Dsun.reflect.debugModuleAccessChecks
to see if you get any stack traces to debug this?
-Alan
