You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Guillaume Laforge <gl...@gmail.com> on 2017/03/24 20:36:58 UTC
Testing the Java 8 / Parrot parser online!
Hi all,
I've deployed a version of the venerable Groovy Web Console that uses the
Parrot parser!
And we'd love if you could try it out and report your findings.
You don't have to install anything, just go online, and run some scripts or
classes, using Java 8 syntax constructs and APIs, and see how well it works.
I've blogged about it here:
http://glaforge.appspot.com/article/testing-java-8-snippets-on-the-new-app-engine-java-8-runtime
And you can try it here online directly, without installing anything:
https://cafe-huitre.appspot.com/
It's built with Java 8, and runs on the upcoming version of Google App
Engine's Java runtime running on an OpenJDK 8. It's using the "indy" jar,
thus with the invoke dynamic support automatically.
I'll deploy that version at some point to the usual web console URL, once
we have an official release of the Parrot parser.
What we'd like is you to go and try it out :-)
Please spend a moment to try different things, and if you find any problem,
please report them back here.
Thanks for your help!
Guillaume
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Testing the Java 8 / Parrot parser online!
Posted by Paul King <pa...@asert.com.au>.
Well, master is currently destined for Groovy 3 (or perhaps 4 -
depending on how things pan out and how we finalise numbering) and it
is ear-marked for JDK8+, so we could start making those changes soon.
I was going to wait until I split off the GROOVY_2_6_X branch which
I'll do after working out the best way to do the Parrot/Parrot
back-port merging.
Cheers, Paul.
On Sun, Mar 26, 2017 at 7:23 AM, John Wagenleitner
<jo...@gmail.com> wrote:
> On Sat, Mar 25, 2017 at 1:26 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>>
>> On 25.03.2017 07:52, Russel Winder wrote:
>>>
>>> On Fri, 2017-03-24 at 21:36 +0100, Guillaume Laforge wrote:
>>>>
>>>> […]
>>>>
>>>> It's built with Java 8, and runs on the upcoming version of Google
>>>> App
>>>> Engine's Java runtime running on an OpenJDK 8. It's using the "indy"
>>>> jar,
>>>> thus with the invoke dynamic support automatically.
>>>> […]
>>>
>>>
>>> What is the exact difference between the indy artefacts and the non-
>>> indy artefacts?
>>>
>
> My understanding is that the only difference between the "-indy" and
> non-indy jars pertains to class files generated from .groovy source files
> within the Groovy project itself. Using the indy jars does affect scripts
> compiled or run against those jars, the default is still the legacy callsite
> code. In order compile with indy you'd still have to set the indy setting
> in the compiler config or pass -indy to groovyc. Since core contains very
> few groovy source files (I think maybe just one), using the -indy jars would
> mainly affect those using subprojects such as groovy-console,
> groovy-docgenerator, etc. that are mostly written using Groovy.
>
>
>>>
>>> Why are we still making two complete sets of artefacts int eh Groovy
>>> build, surely now we should have just one.
>>
>>
>> I cannot suggest to users to use indy with a normal JDK7, so the minimum
>> requirement for it is JDK8. And we are not there yet.
>>
>> bye Jochen
>>
>
> Based on what I've seen I agree, at least for making indy the default mode
> for compilation would be best to wait until jdk8 is the min version.
Re: Testing the Java 8 / Parrot parser online!
Posted by John Wagenleitner <jo...@gmail.com>.
On Sat, Mar 25, 2017 at 1:26 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 25.03.2017 07:52, Russel Winder wrote:
>
>> On Fri, 2017-03-24 at 21:36 +0100, Guillaume Laforge wrote:
>>
>>> […]
>>>
>>> It's built with Java 8, and runs on the upcoming version of Google
>>> App
>>> Engine's Java runtime running on an OpenJDK 8. It's using the "indy"
>>> jar,
>>> thus with the invoke dynamic support automatically.
>>> […]
>>>
>>
>> What is the exact difference between the indy artefacts and the non-
>> indy artefacts?
>>
>>
My understanding is that the only difference between the "-indy" and
non-indy jars pertains to class files generated from .groovy source files
within the Groovy project itself. Using the indy jars does affect scripts
compiled or run against those jars, the default is still the legacy
callsite code. In order compile with indy you'd still have to set the indy
setting in the compiler config or pass -indy to groovyc. Since core
contains very few groovy source files (I think maybe just one), using the
-indy jars would mainly affect those using subprojects such as
groovy-console, groovy-docgenerator, etc. that are mostly written using
Groovy.
> Why are we still making two complete sets of artefacts int eh Groovy
>> build, surely now we should have just one.
>>
>
> I cannot suggest to users to use indy with a normal JDK7, so the minimum
> requirement for it is JDK8. And we are not there yet.
>
> bye Jochen
>
>
Based on what I've seen I agree, at least for making indy the default mode
for compilation would be best to wait until jdk8 is the min version.
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser
online!]
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.03.2017 16:26, Andres Almiray wrote:
> Measure, don't guess! ;-)
>
> Perhaps setting up a set of JMH benchmarks would help? I know there's a
> Gradle plugin for it (wink wink, nudge nudge).
you mean after it got fixed? ;)
bye Jochen
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser
online!]
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.03.2017 17:01, Russel Winder wrote:
> On Mon, 2017-03-27 at 16:26 +0200, Andres Almiray wrote:
>> Measure, don't guess! ;-)
>>
>> Perhaps setting up a set of JMH benchmarks would help? I know there's
>> a
>> Gradle plugin for it (wink wink, nudge nudge).
>
> I certainly agree with measure don't guess. However C�dric phrased it
> in terms of stay with non-indy. I disagree, I think we should switch
> and then make indy faster than non-indy. Using the word "legacy" is
> important here. The non-indy stuff is legacy, do we really want Groovy
> to be comprised of legacy code?
I think it is good to get rid of the old callsite caching simply because
it will reduce the code size a lot.
bye Jochen
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser
online!]
Posted by Russel Winder <ru...@winder.org.uk>.
On Mon, 2017-03-27 at 16:26 +0200, Andres Almiray wrote:
> Measure, don't guess! ;-)
>
> Perhaps setting up a set of JMH benchmarks would help? I know there's
> a
> Gradle plugin for it (wink wink, nudge nudge).
I certainly agree with measure don't guess. However Cédric phrased it
in terms of stay with non-indy. I disagree, I think we should switch
and then make indy faster than non-indy. Using the word "legacy" is
important here. The non-indy stuff is legacy, do we really want Groovy
to be comprised of legacy code?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]
Posted by Andres Almiray <aa...@gmail.com>.
Measure, don't guess! ;-)
Perhaps setting up a set of JMH benchmarks would help? I know there's a
Gradle plugin for it (wink wink, nudge nudge).
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Mon, Mar 27, 2017 at 4:13 PM, Cédric Champeau <ce...@gmail.com>
wrote:
> I would only make indy the default if we have performance tests showing
> that it's as fast as, or better than the legacy call site caching, with JDK
> 8+. There's a "performance" submodule that we could use for that purpose
> too. As far as I remember, not too far away, there were quite a few cases
> where indy was slower, in particular when primitive types are involved,
> even on JDK 8. If we are faster, then it's obviously a big +1, but we
> shouldn't speculate here.
>
> 2017-03-27 16:03 GMT+02:00 Paul King <pa...@asert.com.au>:
>
>> Russel, seems we were thinking about the same things. I responded to
>> the earlier thread. Does that answer your question?
>> In summary, we could start trying to move to indy only on master. I
>> think stability wise we are in good shape. There are some question
>> marks still however about indy performance in some circumstances, so
>> we no doubt would want to do a fresh round of performance checks.
>>
>> Cheers, Paul.
>>
>> On Mon, Mar 27, 2017 at 11:35 PM, Russel Winder <ru...@winder.org.uk>
>> wrote:
>> > On Sat, 2017-03-25 at 09:26 +0100, Jochen Theodorou wrote:
>> >> […]
>> >>
>> >> I cannot suggest to users to use indy with a normal JDK7, so the
>> >> minimum
>> >> requirement for it is JDK8. And we are not there yet.
>> >
>> > I have to admit I am still of the opinion that you define a version
>> > that will be the last version compatible with infrastructure X and the
>> > say, if you want to use a later version upgrade your infrastructure. I
>> > think Groovy is past that point with JVM; I do not see why development
>> > of our product should be beholden to the inability of people to upgrade
>> > from Java 7 to Java 8.
>> >
>> > Are we going to say that Groovy 2.5 will only work with JDK8 or does
>> > that have to wait for 2.6 or 3.0? Given master is no beyond 2.5 can we
>> > get rid of the two build set up for master and just have indy?
>> >
>> > --
>> > Russel.
>> > ============================================================
>> =================
>> > Dr Russel Winder t: +44 20 7585 2200 <+44%2020%207585%202200>
>> voip: sip:russel.winder@ekiga.net
>> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
>> > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>>
>
>
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser
online!]
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.03.2017 16:13, C�dric Champeau wrote:
> I would only make indy the default if we have performance tests showing
> that it's as fast as, or better than the legacy call site caching, with
> JDK 8+. There's a "performance" submodule that we could use for that
> purpose too. As far as I remember, not too far away, there were quite a
> few cases where indy was slower, in particular when primitive types are
> involved, even on JDK 8. If we are faster, then it's obviously a big +1,
> but we shouldn't speculate here.
if you remember such a case tell me ;)
bye Jochen
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]
Posted by Cédric Champeau <ce...@gmail.com>.
I would only make indy the default if we have performance tests showing
that it's as fast as, or better than the legacy call site caching, with JDK
8+. There's a "performance" submodule that we could use for that purpose
too. As far as I remember, not too far away, there were quite a few cases
where indy was slower, in particular when primitive types are involved,
even on JDK 8. If we are faster, then it's obviously a big +1, but we
shouldn't speculate here.
2017-03-27 16:03 GMT+02:00 Paul King <pa...@asert.com.au>:
> Russel, seems we were thinking about the same things. I responded to
> the earlier thread. Does that answer your question?
> In summary, we could start trying to move to indy only on master. I
> think stability wise we are in good shape. There are some question
> marks still however about indy performance in some circumstances, so
> we no doubt would want to do a fresh round of performance checks.
>
> Cheers, Paul.
>
> On Mon, Mar 27, 2017 at 11:35 PM, Russel Winder <ru...@winder.org.uk>
> wrote:
> > On Sat, 2017-03-25 at 09:26 +0100, Jochen Theodorou wrote:
> >> […]
> >>
> >> I cannot suggest to users to use indy with a normal JDK7, so the
> >> minimum
> >> requirement for it is JDK8. And we are not there yet.
> >
> > I have to admit I am still of the opinion that you define a version
> > that will be the last version compatible with infrastructure X and the
> > say, if you want to use a later version upgrade your infrastructure. I
> > think Groovy is past that point with JVM; I do not see why development
> > of our product should be beholden to the inability of people to upgrade
> > from Java 7 to Java 8.
> >
> > Are we going to say that Groovy 2.5 will only work with JDK8 or does
> > that have to wait for 2.6 or 3.0? Given master is no beyond 2.5 can we
> > get rid of the two build set up for master and just have indy?
> >
> > --
> > Russel.
> > ============================================================
> =================
> > Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]
Posted by Paul King <pa...@asert.com.au>.
Russel, seems we were thinking about the same things. I responded to
the earlier thread. Does that answer your question?
In summary, we could start trying to move to indy only on master. I
think stability wise we are in good shape. There are some question
marks still however about indy performance in some circumstances, so
we no doubt would want to do a fresh round of performance checks.
Cheers, Paul.
On Mon, Mar 27, 2017 at 11:35 PM, Russel Winder <ru...@winder.org.uk> wrote:
> On Sat, 2017-03-25 at 09:26 +0100, Jochen Theodorou wrote:
>> […]
>>
>> I cannot suggest to users to use indy with a normal JDK7, so the
>> minimum
>> requirement for it is JDK8. And we are not there yet.
>
> I have to admit I am still of the opinion that you define a version
> that will be the last version compatible with infrastructure X and the
> say, if you want to use a later version upgrade your infrastructure. I
> think Groovy is past that point with JVM; I do not see why development
> of our product should be beholden to the inability of people to upgrade
> from Java 7 to Java 8.
>
> Are we going to say that Groovy 2.5 will only work with JDK8 or does
> that have to wait for 2.6 or 3.0? Given master is no beyond 2.5 can we
> get rid of the two build set up for master and just have indy?
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser
online!]
Posted by Russel Winder <ru...@winder.org.uk>.
On Sat, 2017-03-25 at 09:26 +0100, Jochen Theodorou wrote:
> […]
>
> I cannot suggest to users to use indy with a normal JDK7, so the
> minimum
> requirement for it is JDK8. And we are not there yet.
I have to admit I am still of the opinion that you define a version
that will be the last version compatible with infrastructure X and the
say, if you want to use a later version upgrade your infrastructure. I
think Groovy is past that point with JVM; I do not see why development
of our product should be beholden to the inability of people to upgrade
from Java 7 to Java 8.
Are we going to say that Groovy 2.5 will only work with JDK8 or does
that have to wait for 2.6 or 3.0? Given master is no beyond 2.5 can we
get rid of the two build set up for master and just have indy?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Testing the Java 8 / Parrot parser online!
Posted by Jochen Theodorou <bl...@gmx.org>.
On 25.03.2017 07:52, Russel Winder wrote:
> On Fri, 2017-03-24 at 21:36 +0100, Guillaume Laforge wrote:
>> [\u2026]
>>
>> It's built with Java 8, and runs on the upcoming version of Google
>> App
>> Engine's Java runtime running on an OpenJDK 8. It's using the "indy"
>> jar,
>> thus with the invoke dynamic support automatically.
>> [\u2026]
>
> What is the exact difference between the indy artefacts and the non-
> indy artefacts?
>
> Why are we still making two complete sets of artefacts int eh Groovy
> build, surely now we should have just one.
I cannot suggest to users to use indy with a normal JDK7, so the minimum
requirement for it is JDK8. And we are not there yet.
bye Jochen
Re: Testing the Java 8 / Parrot parser online!
Posted by Russel Winder <ru...@winder.org.uk>.
On Fri, 2017-03-24 at 21:36 +0100, Guillaume Laforge wrote:
> […]
>
> It's built with Java 8, and runs on the upcoming version of Google
> App
> Engine's Java runtime running on an OpenJDK 8. It's using the "indy"
> jar,
> thus with the invoke dynamic support automatically.
> […]
What is the exact difference between the indy artefacts and the non-
indy artefacts?
Why are we still making two complete sets of artefacts int eh Groovy
build, surely now we should have just one.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Testing the Java 8 / Parrot parser online!
Posted by Guillaume Laforge <gl...@gmail.com>.
Currently, lambdas are indeed backed by Groovy closures, or use the SAM
type coercion mechanism.
On Fri, Mar 24, 2017 at 10:06 PM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:
> That is awesome. If the Java 8 syntax is supported, does that mean Groovy
> will support lambdas? One thing that saddened me about using Java 8 from
> Groovy is that you have the overhead of closure classes/meta class and the
> “dynamic” conversion/proxy into the Java functional interfaces, while the
> same code written in Java uses the lambda functionality which appears to
> return a singleton instance of a VM-generated class with presumably much
> less overhead.
>
>
>
> Jason
>
>
>
> *From:* Guillaume Laforge [mailto:glaforge@gmail.com]
> *Sent:* Friday, March 24, 2017 4:37 PM
> *To:* users@groovy.apache.org
> *Subject:* Testing the Java 8 / Parrot parser online!
>
>
>
> Hi all,
>
>
>
> I've deployed a version of the venerable Groovy Web Console that uses the
> Parrot parser!
>
> And we'd love if you could try it out and report your findings.
>
> You don't have to install anything, just go online, and run some scripts
> or classes, using Java 8 syntax constructs and APIs, and see how well it
> works.
>
>
>
> I've blogged about it here:
>
> http://glaforge.appspot.com/article/testing-java-8-
> snippets-on-the-new-app-engine-java-8-runtime
>
>
>
> And you can try it here online directly, without installing anything:
>
> https://cafe-huitre.appspot.com/
>
>
>
> It's built with Java 8, and runs on the upcoming version of Google App
> Engine's Java runtime running on an OpenJDK 8. It's using the "indy" jar,
> thus with the invoke dynamic support automatically.
>
>
>
> I'll deploy that version at some point to the usual web console URL, once
> we have an official release of the Parrot parser.
>
>
>
> What we'd like is you to go and try it out :-)
>
> Please spend a moment to try different things, and if you find any
> problem, please report them back here.
>
>
>
> Thanks for your help!
>
>
>
> Guillaume
>
>
>
> --
>
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
>
> Developer Advocate @ Google Cloud Platform
>
>
>
> Blog: http://glaforge.appspot.com/
>
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Testing the Java 8 / Parrot parser online!
Posted by Jochen Theodorou <bl...@gmx.org>.
On 24.03.2017 22:06, Winnebeck, Jason wrote:
> That is awesome. If the Java 8 syntax is supported, does that mean
> Groovy will support lambdas? One thing that saddened me about using Java
> 8 from Groovy is that you have the overhead of closure classes/meta
> class and the \u201cdynamic\u201d conversion/proxy into the Java functional
> interfaces, while the same code written in Java uses the lambda
> functionality which appears to return a singleton instance of a
> VM-generated class with presumably much less overhead.
Groovy will be supporting that at one point I think.
bye Jochen
RE: Testing the Java 8 / Parrot parser online!
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
That is awesome. If the Java 8 syntax is supported, does that mean Groovy will support lambdas? One thing that saddened me about using Java 8 from Groovy is that you have the overhead of closure classes/meta class and the “dynamic” conversion/proxy into the Java functional interfaces, while the same code written in Java uses the lambda functionality which appears to return a singleton instance of a VM-generated class with presumably much less overhead.
Jason
From: Guillaume Laforge [mailto:glaforge@gmail.com]
Sent: Friday, March 24, 2017 4:37 PM
To: users@groovy.apache.org
Subject: Testing the Java 8 / Parrot parser online!
Hi all,
I've deployed a version of the venerable Groovy Web Console that uses the Parrot parser!
And we'd love if you could try it out and report your findings.
You don't have to install anything, just go online, and run some scripts or classes, using Java 8 syntax constructs and APIs, and see how well it works.
I've blogged about it here:
http://glaforge.appspot.com/article/testing-java-8-snippets-on-the-new-app-engine-java-8-runtime
And you can try it here online directly, without installing anything:
https://cafe-huitre.appspot.com/
It's built with Java 8, and runs on the upcoming version of Google App Engine's Java runtime running on an OpenJDK 8. It's using the "indy" jar, thus with the invoke dynamic support automatically.
I'll deploy that version at some point to the usual web console URL, once we have an official release of the Parrot parser.
What we'd like is you to go and try it out :-)
Please spend a moment to try different things, and if you find any problem, please report them back here.
Thanks for your help!
Guillaume
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.