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
