Groovy with Jigsaw

[Alan Bateman]

On 11/09/2015 13:11, Jochen Theodorou wrote:
> 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.
Yes, this a incompatible change as InaccessibleObjectException is new. 
We might need to look at this again but changing it to security 
exception (or a sub-type) is really icky. One thing that would be useful 
to find setAccessible usages in other libraries to see if security 
exception is caught or handled.


>>
>> Second: AccessibleObject#setAccessible was made final
I have a patch to resolve this one, just needs more testing, there was 
no intention to break anyone with this. My guess is that it is is very 
rare to extent AccessibleObject outside of java.lang.reflect.


>
> 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.
It's always been possible to configure the system class loader to be 
something else. So I'm curious what you do if it is a URLClassLoader, 
are you just looking for the class path?

> :
>
> 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.
Nashorn is updated in the EA builds to work with modules, it is spinning 
dynamic modules at run-time. I think it requires building up examples of 
real needs before thinking about an API here.

-Alan