Sounds good. We have JDK8 as minimum for Groovy 3 but can
utilise the plugin system as needed. If we consider value types,
that sounds more like Groovy 4 to me. But in any case, we should just
try to get a spike branch happening and we can merge into wherever
makes sense once things are ready.
Cheers, Paul.
On Thu, Aug 9, 2018 at 4:05 AM Jochen Theodorou <blackd...@gmx.org> wrote:
> 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
>
