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 construc
t
.
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/
