groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Testing the Java 8 / Parrot parser online!
Date Mon, 27 Mar 2017 13:35:17 GMT
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
<john.wagenleitner@gmail.com> wrote:
> On Sat, Mar 25, 2017 at 1:26 AM, Jochen Theodorou <blackdrag@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.

Mime
View raw message