Better tools for adjusting to strong encapsulation

[Jochen Theodorou]

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