Groovy with Jigsaw

[Alan Bateman]

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 at 9.0/Native Method)
> [23:53:08]W:[Gradle failure report] at 
> java.lang.ClassLoader.defineClass(java.base at 9.0/ClassLoader.java:820)
> [23:53:08]W:[Gradle failure report] at 
> java.security.SecureClassLoader.defineClass(java.base at 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