Hi all,
during JCrete I was playing around with removing some of those
setAccessible calls and found one quite problematic case.
AS many here know we have some implementation details for our Closures,
one of them is the following: You can subclass Closure and declare a
doCall method which will the drive part of the logic (accepted arguments
and such) In fact all of our Closures usages in Groovy currently end up
in one or more doCall methods.
Now the problem is, if you declare an anonymous inner class of a Closure
with a doCall method in Java (yes, we do this in our codebase), then it
is quite difficult to give the runtime (or DGM) access to this method.
First I thought the super class Closure could have access if the method
is at least public, but AICs are not public, which automatically
restricts access to methods declared in them, not available otherwise.
I then started to play around with the AIC exhibiting a method handle to
Closure to allow Closure to call the doCall method using the
MethodHandles API. But this will of course add several lines of code to
the subclass, that where not needed before.
And then not to forget about our plan to make our Closures into
something more similar to lambdas in Java.
That did make me think...
(1) maybe Closure should have a factory method that allows a
MethodHandle (or more than one) to be properly registered (ClassValue I
am thinking here), to allow us to call doCall from call
(2) maybe the method should be more convenient and take a Lookup object
and method name instead for the user
(3) even better would be to be able to use a Java lambda for a Closure
but the Java type system does not really allow a nice solution for that,
which means Closure would become:
interface Closure {
Object call(Object[] args);
static Closure buildClosure(MethodHandle... h) {...}
static Closure buildClosure(Lookup lookup, Class<?> baseClass, String
methodName) /*throws ReflectiveOeprationException */{...}
// plus more here
}
(4) all old code using one of the other call methods or any doCall would
break. Java usage would have to change to either lambdas or one of the
buildClosure methods. Groovy usage could use the MethodHandle based
version and only the MethodHandle based version would include meta
information like the parameter count and types. Accessing this
information lazy could make it a thin wrapper around the handle,
allowing transformations from Closure to SAM cases, while still holding
some kind of reference.
(5) If I think of as lightweight as possible I automatically think of
ValueTypes... Then I wonder... would we rewrite Closure as ValueType of
a MethodHandle at some point (post JDK 11). If yes, should we
investigate more here and maybe go for JKD11+ instead of JDK9 with
Groovy 3? Frankly There is no good reason for me to go with Java 9
anymore, since it is already outdated and not even with LTS.
What do others think about this? Or should I just go an break some arms
and legs... ahm...Groovy code ?
bye Jochen
