From dev-return-5176-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Fri Aug 10 19:24:10 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 24107180676 for ; Fri, 10 Aug 2018 19:24:09 +0200 (CEST) Received: (qmail 44554 invoked by uid 500); 10 Aug 2018 17:24:09 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 44141 invoked by uid 99); 10 Aug 2018 17:24:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2018 17:24:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0BBA11807B7 for ; Fri, 10 Aug 2018 17:24:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.97 X-Spam-Level: * X-Spam-Status: No, score=1.97 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=asert-com-au.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id HWKcQ4jwYeKf for ; Fri, 10 Aug 2018 17:24:04 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2FDE25F3DF for ; Fri, 10 Aug 2018 17:24:04 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id s198-v6so17024875oih.11 for ; Fri, 10 Aug 2018 10:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asert-com-au.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=+oJ3OkTPPCENRLljKzWVWUM1xFHP3Kc4efcPgOnA9QI=; b=fC8KsHMHss6DC40OVBvbC+SVXyetgNl1q5Cy1vg2fen7Oosk4zhflJ8/Zz3Vhzke+I v7sDQFrlRkM7MVIPHZGjXHaULn9VPmLp2CX3oHMa7wVkTGS2FlNNtKBlkf7UYKuhFtrA OlS6LzUBqIC7I/G3Z2zDxCR3UAZ4ondgToZlSHi6l6wCcd5cmQ669f1bVtTZiEvEmtkS gKxTKjGkWEInMrlWKLpfqARektOm0i8h0/omdF5/KpnOSVVLThtWich6nw39ehoCKeYl md3JjV4/THVLvltJONYOel9ys8DfyLHkQwUtDwrPXXKreQmSDcCd5QWNbaYKJWD7ztYy PNTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=+oJ3OkTPPCENRLljKzWVWUM1xFHP3Kc4efcPgOnA9QI=; b=P8CnD49yxKOrBGDdmqRXWAJdWCq15ug85QYCo734XeAY18l5zok5z4JgegJ025VX6+ rVVeqlhHvIwsI3p1sfvLdh0a5iQDuytnwqxAYq/eriQTW/Jgn51No1Q0H1tJ2ZFQnqWI TQcdjOPoPoofRLpJwwDSrjjHZOo+f8UeOSjHBP16VaZfT9RLM/wvVWb+4UmMp5q7g9jj zaSiX5z2zjbtz3FibOdmqQoXn8r0e7fdFDp+tl2VgE2Jb81I2WTdT/gAw2LJPzJgjMy2 6t/CmAdNNr3Gtug/z7efh2Q2MfqFFk/Aa0H3lfcTi95jfNh1lH/WQday32CKJCRY35iR vTjg== X-Gm-Message-State: AOUpUlHT+lmFg68NEaS/c34A77TE/rwicq9tAYDw3CpysE03CIb8j//+ hF9uOO+r/zkb8MF0OGKYoFuEdB3sjUEye9iRAE3PWBJ3 X-Google-Smtp-Source: AA+uWPzfLeDb6xyntP5AN6HU4HrZFtyFzb5E4ZA2E2TahsYQ0tUAkdiAExbmhJY7P3rVyAVExAR1gpvdlooQrBzOFTA= X-Received: by 2002:aca:32c4:: with SMTP id y187-v6mr7902613oiy.315.1533921842754; Fri, 10 Aug 2018 10:24:02 -0700 (PDT) MIME-Version: 1.0 References: <2f03539b-3231-e7e7-a41d-f58b7cd438f8@gmx.org> In-Reply-To: <2f03539b-3231-e7e7-a41d-f58b7cd438f8@gmx.org> Reply-To: paulk@asert.com.au From: Paul King Date: Sat, 11 Aug 2018 03:23:52 +1000 Message-ID: Subject: Re: Groovy 3 + JDK9 and problems with our Closure To: dev@groovy.apache.org Content-Type: multipart/alternative; boundary="0000000000008cff3b05731802a2" --0000000000008cff3b05731802a2 Content-Type: text/plain; charset="UTF-8" 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 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 > --0000000000008cff3b05731802a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good. We have JDK8 as minimum for Groovy 3 but can<= div>utilise the plugin system as needed. If we consider value types,
<= div>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.

Chee= rs, Paul.


On Thu, Aug 9, 2018 at 4:05 AM Jochen Theodorou <blackdrag@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 {
=C2=A0 =C2=A0Object call(Object[] args);
=C2=A0 =C2=A0static Closure buildClosure(MethodHandle... h) {...}
=C2=A0 =C2=A0static Closure buildClosure(Lookup lookup, Class<?> base= Class, String
methodName) /*throws ReflectiveOeprationException */{...}
=C2=A0 =C2=A0// 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
--0000000000008cff3b05731802a2--