Groovy with Jigsaw

[Jochen Theodorou]

Am 11.09.2015 13:00, schrieb 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
.

It doesn't end there. I have yet to investigate what it means if the 
system class loader is no URLClassLoader per default anymore. This will 
have impact on Groovy's @Grab. This will cause problems with for example 
loading jdbc drivers at runtime.

And if the assumptions about the module system in my initial post all 
are correct (nobody commented on those), I see trouble for Groovy 
calling methods in general. If we have to make a Groovy module and 
modules written in Groovy have to allow Groovy access to internal APIs, 
to be able to make normal method calls, then it means the module system 
is bypassed, because then any other Groovy program from any other module 
can use Groovy to access internals. Which also means Java programs can 
use Groovy to exploit everything of any Groovy module.

And somebody has to explain to me why this is supposed to be different 
for Nashorn. I would imagine it is even worse there, since Nashorn can 
see internal APIs, that are hidden to others and since it is part of the 
JDK.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/