Groovy with Jigsaw

[Uwe Schindler]

Just to conclude, there are 2 problems around setAccessible:

First, it throws a new Exception type. This makes almost any Groovy script fail at some point, because it tries to add some meta class on the scripting level, and this call setAccessible on all fields and methods of any class used in the script, only catching SecurityException but not the new one. My preferred solution would be to make the new InaccessibleObjectException as subclass of SecurityException (and add some documentation why this is done like that). Please note this does not differ from current Java 8 spec, where setAccessible may throw SecurityException without a security manager on some special objects (Class constructor). I agree, this is also strange (UOE would be more correct), but the same solution could be taken here, too.

Second: AccessibleObject#setAccessible was made final, this breaks "delegators" like the one in Google Guava, which is a library used in like 50% of all larger software projects. Changing methods to be final in abstract classes is always a hard break, because abstract classes are there to be extended. The workaround may be to make the implementations final (which they are already, because Method, Field,... classes are final). Maybe just move the implementation into the final subclasses (with stupid code duplication, alternatively use a static helper class to avoid the code duplication). We had a similar issue in Java 8 EA builds (reported by Lucene at that time), where isAnnotationPresent() was moved as *default* method to the interface AnnotatedObject and then the impl in Field/Method/... was removed. This caused compiler failures for code compiled with source/target 1.7. The fix was to define the method in all subclasses but delegate to the interface with some super-like construct.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/


> -----Original Message-----
> From: Jochen Theodorou [mailto:blackdrag at gmx.org]
> Sent: Friday, September 11, 2015 11:46 AM
> To: Alan Bateman; Cédric Champeau
> Cc: Uwe Schindler; jigsaw-dev at openjdk.java.net
> Subject: Re: Groovy with Jigsaw
> 
> Am 11.09.2015 11:33, schrieb Alan Bateman:
> >
> > On 11/09/2015 10:21, Jochen Theodorou wrote:
> >>
> >> the error in Guava is not a failed attempt, it is a VerifyError,
> >> because AccessibleObject#setAccessible is now final and
> >> com.google.common.reflect.Element overrides the method.
> >>
> >> As far as I have seen Guava makes a parallel reflective structure of
> >> a class to be able to better handle them. A the same time they proxy
> >> to their counter parts, but do also implement interfaces like Member.
> >> That requires for example to override setAccessible, which will just
> >> make the same call on the delegate. I don't see how they can easily
> >> fix that without giving up their mirror structure and have it
> >> exchangeable with the java reflective classes at the same time. But I
> >> am not on the guava team, so they know hopefully better
> > Okay, I mis-read one of the mails and assumed that setAccessible was
> > failing and leading to other errors.
> 
> It does fail for any Groovy script, that invokes any method on an Object, that
> has a declaring class, which is made inaccessible through the module system,
> due to the new exception being thrown. Example:
> 
> ClassLoader.getSystemClassLoader().toString()
> 
> > In the current builds then setAccessible is final, and yes, this is an
> > incompatible change. The reason for this is that the method is now @CS.
> > I think we need to consider changing this so that setAccessible is
> > overridden in the final Field, Constructor, and Method classes instead.
> 
> Does @CS then mean guava will then possibly interfere with the security
> manager logic, since it introduces a new layer of calling code in between?
> 
> bye Jochen
> 
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/