On 23.03.2017 01:16, Claes Redestad wrote:
[...]
the warnings you are seeing are from the groovy runtime trying to
determine - in a pre JDK9 compatible way - if it is allowed to call the
methods on Objecz. This happens in a first step by setAccessible on all
methods using the array version, and if that fails by using the normal
setAccessible on each method (which will contribute to much longer
startup times). At no point our runtime or the program you wrote are
trying to call finalize, clone or registerNatives.
For determining capabilities in this manner it might be possible to
use the new AccessibleObject.canAccess[1], which should avoid any
warnings?
/Claes
[1]
http://download.java.net/java/jdk9/docs/api/java/lang/reflect/AccessibleObject.html#canAccess-java.lang.Object-
I guess so. I mean normally we request that you open up the Objects to
the runtime and the runtime then decides by itself if class X has access
to class Y via runtime. canAccess will avoid the warnings, and
completely avoid them I think for the case of everything being on the
classpath. It will not avoid the add-opens required for the runtime to
access objects from class X in module M to class Y in the same Module
via Groovy runtime. Because even if we use MethodHandles, the handle is
still produced from a Method object in reflection and that will mean we
still require the runtime accessing this.
And actually I don't think we can exclude the reflective part, because
we have to do runtime method selection. We cannot query for a method
directly, we have to query for all methods of a certain name, which is
impossible, so we have to take a look at all methods of a class. And I
mean independent of the accessibility modifier.
So does canAccess help? Yes, in the classpath scenario, not in the
module scenario. But at least that scenario is currently not likely
bye Jochen
