Re: [VOTE] Add a shorthand "final var" keyword

[Keith Suderman]

-1

I agree with Anne and the others;  I see no compelling use case for this.  If 
making variable definitions line up is the goal then make your variable 
definitions line up... that is what whitespace was invented for.  And I can't 
think of a single keyword (other than "final" or "const") that would make me 
think, "Hey, that variable can't be changed".

- Keith

> On Apr 28, 2020, at 8:09 AM, mojo2012  wrote:
> 
> Dear development community,
> 
> I'm a long time java developer and I'm used to add "final" to my variable
> definition: final var name = "a"
> 
> I think the *"var"* keyword (and the old "*def*" keyword) itself helps a
> lot, but seeing "*var*" and "*final var*" not being aligned properly in code
> makes me crazy.
> 
> As we have def and var in groovy, wouldn't it be nice to have a val or let
> in groovy too, that is just a short form of "final var"?
> 
> Although personally I would prefer "*val*" I do understand that some people
> might have problems differentiating "*var*" and "*val*", hence the "*let*".
> Both *Kotlin* and *Scala* went for the "val" keyword as well - so it might
> not bee too bad.
> 
> Anyway I created a JIRA ticket for this:
> https://issues.apache.org/jira/browse/GROOVY-9308
> And I created a *patch PR*: https://github.com/apache/groovy/pull/1236
> 
> The patch as of now contains both the "let" and "val" syntax. I added tests
> to check if the actual variable is final. Those tests all seem find. But I
> wasn't able to see "final val" as syntax error (so the test currently
> fails).
> 
> I'm looking forward to get some feedback from you (hopefully positive :-))
> 
> [ ] +1 Add either val or let as new shortcut for "final def"/"final var"
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 I don't like this feature because ...
> 
> 
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Groovy multiplication

[Keith Suderman]

The same reason it does in Java; the result is larger than Integer.MAX_VALUE 
(ie. integer overflow).  You need to tell Java/Groovy to use a larger type.

System.out.println(86400L*1000*30);

> On Dec 8, 2019, at 3:26 PM, Edmond Kemokai  wrote:
> 
> Is there a reason this should yield a negative number in groovy?
> 
> 86400*1000*30
> 

Re: Remembering imports between script invocations

[Keith Suderman]

Hi David,

I am not a Groovy committer and I am not that familiar with the Groovy code 
base so _I_ can't revise the JSR-223 implementation.  I did take a quick look 
at the code, and other than having "GroovyScriptEngine" in their names the two 
classes (GroovyScriptEngine and GroovyScriptEngineImpl) have nothing in common 
and parse/load Groovy code in completely different ways.  I suspect adding a 
feature like you want would be a non-trivial undertaking.  Maybe one of the 
active committers (Paul, Daniel, et al)  can comment.

However, I suspect that the GroovyScriptEngineImpl class is "crippled" by 
JSR-223 itself as it caters to the lowest common denominator

- Keith

> On Oct 31, 2018, at 12:12 PM, David Ekholm  wrote:
> 
> Hi Keith,
> 
> I'm "resurrecting" this old thread in an attept to see if we can use Groovy 
> as the next scritpting language in jAlbum. What I'd really want to achive is 
> to supply a number of default star imports. This is expecially important as 
> Groovy sadly doesn't remember imports between script invocations.
> 
> I looked at your code suggetion below and tried to fit it to JSR-223 
> (javax.script API) but it fails as the GroovyScriptEngineImpl class I get 
> from that API doesn't extend the GroovyScriptEngine class. It's only the 
> GroovyScriptEngine class that supplies the important setConfig method.
> 
> Could you revise the JSR-223 implementation so it isn't unnecessary crippled 
> compared to the GroovyShell API, at very least add the setConfig method to 
> the GroovyScriptEngineImpl class? If we're to use the GroovyShell API, then 
> we need to introduce our own abstraction layer in order to continue 
> supporting multiple scripting languages in jAlbum.
> 
> Regards
> /David, jAlbum founder
> 
>> On 10 Feb 2018, at 21:25, Keith Suderman > <mailto:suder...@anc.org>> wrote:
>> 
>> Import statements are really just shortcuts to tell the compiler how to 
>> resolve class names so there is nothing to "remember" between invocations, 
>> that is, nothing gets added to the Binding.
>> 
>> I am not familiar with the javax.script API, but I suspect that you will 
>> have to provide your own ScriptEngine implementation as you will need to 
>> modify the CompilerConfiguration object the GroovyShell is using to compile 
>> the Groovy code.  For example:
>> 
>> CompilerConfiguration configuration = new CompilerConfiguration()
>> GroovyShell compiler = new GroovyShell(configuration)
>> println compiler.evaluate('json=\'{"foo":"bar"}\'')
>> println compiler.evaluate("groovy.json.JsonOutput.prettyPrint(json)")
>> 
>> /* Fails: MissingPropertyException */
>> /* println compiler.evaluate("JsonOutput.prettyPrint(json)") */
>> 
>> ImportCustomizer imports = new ImportCustomizer()
>> imports.addStarImports("groovy.json")
>> configuration.addCompilationCustomizers(imports)
>>  // Works, the compiler can now resolve groovy.json.JsonOutput
>> println compiler.evaluate("JsonOutput.prettyPrint(json)")
>> 
>> The difficult part will be "hooking" into the compiler to know when an 
>> import statement is used so you can update your CompilerConfiguration 
>> object.  I am sure the really clever programmers here could come up with 
>> some sort of AST transform that would do this.  However, depending on what 
>> you are allowed to do one option would be to tell your users that you have a 
>> "Groovy DSL" and then implement an "include" method that users would use to 
>> "import" Java packages.
>> 
>> println eval('json=\'{"foo":"bar"}\'')
>> println eval('include "groovy.json"')
>> println eval('JsonOutput.prettyPrint(json)')
>>  
>> Object eval(String code) {
>> Script script = compiler.parse(code)
>> ExpandoMetaClass metaClass = new ExpandoMetaClass(script.class, 
>> false)
>> metaClass.include = { String name ->
>> ImportCustomizer includes = new ImportCustomizer()
>> includes.addStarImports(name)
>> configuration.addCompilationCustomizers(includes)
>> "Imported $name"
>> }
>> metaClass.initialize()
>> script.metaClass = metaClass
>> script.run()
>> }
>> 
>> Hopefully that gives you some ideas.
>&g

Re: About simplifying the switch for runtime groovydoc

[Keith Suderman]

> On Oct 24, 2018, at 8:31 PM, Remko Popma  wrote:
> 
> In addition, there is nothing about the long @GroovyDoc notation that tells 
> me the doc string is retained at runtime. So it isn’t actually clearer...

This.  When I first saw @GroovyDoc my initial reaction was, "Of course it is 
GroovyDoc, it is a .groovy file, what else would it be?". I had to Google to 
find the original thread to discover that it was "Runtime GroovyDoc".  So I 
think something like @Runtime would be much clearer and informative than 
@GroovyDoc.

But having said that, I have never said to myself, "I wish I could make this 
GroovyDoc available at runtime." So I would wait to see how the annotation is 
used in the wild before considering shortcuts.

My two cents,
Keith

> 
> Remko.
> 
> (Shameless plug) Every java main() method deserves http://picocli.info 
> <http://picocli.info/>
> 
> On Oct 24, 2018, at 23:12, Guillaume Laforge  <mailto:glafo...@gmail.com>> wrote:
> 
>> Not necessarily. Discussions are better, leading towards a consensus.
>> Polls can have very different outcomes depending on how you define the 
>> questions and answers, how you advertise the poll, how you interpret the 
>> results of the poll, etc.
>> Before any poll, I'd like to hear about those early users of this 
>> non-released-yet feature, to hear what their thoughts are.
>> There's no need to hurry or rush towards adding this shortcut notation.
>> 
>> 
>> On Wed, Oct 24, 2018 at 3:57 PM Daniel.Sun > <mailto:sun...@apache.org>> wrote:
>> Raising a poll may be better way to make decisions ;)
>> 
>> Cheers,
>> Daniel.Sun
>> 
>> 
>> 
>> 
>> -
>> Daniel Sun
>> Apache Groovy committer
>> Blog: http://blog.sunlan.me <http://blog.sunlan.me/>
>> Twitter: @daniel_sun
>> 
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html 
>> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
>> 
>> 
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>> 
>> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
>> Twitter: @glaforge <http://twitter.com/glaforge>
--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






signature.asc
Description: Message signed with OpenPGP

Bug or expected behaviour?

[Keith Suderman]

Hello,

I have a parent class that defines a static final String and a child class that 
references the String in it's constructor.  Essentially:

class Parent {
static final String DEFAULT = 'default'
}
class Child extends Parent {
String value
Child() { this(DEFAULT) }  // Bad type on operand stack
Child(String value) { this.value = value }
}
println new Child().value

However, when I try to run the code I get a "java.lang.VerifyError: Bad type on 
operand stack" (see below).  From my understanding this exception is caused 
when a constructor tries to use a variable/field that has not been initialized 
yet; i.e. the `this(DEFAULT)` in the above example.  However, if I qualify the 
DEFAULT with the class name (i.e. `this(Parent.DEFAULT)`) the code works as 
expected.

Similar code in Java works without DEFAULT being qualified with the superclass 
name.  So I am wondering; is this a bug or a design decision that was made 
somewhere/sometime?

I am using Groovy Version: 2.5.2 JVM: 1.8.0_40 Vendor: Oracle Corporation OS: 
Mac OS X

Cheers,
Keith

Caught: java.lang.VerifyError: Bad type on operand stack
Exception Details:
 Location:
   Child.()V @10: invokeinterface
 Reason:
   Type uninitializedThis (current frame, stack[2]) is not assignable to 
'java/lang/Object'
 Current Frame:
   bci: @10
   flags: { flagThisUninit }
   locals: { uninitializedThis, 
'[Lorg/codehaus/groovy/runtime/callsite/CallSite;' }
   stack: { uninitializedThis, 'org/codehaus/groovy/runtime/callsite/CallSite', 
uninitializedThis }
 Bytecode:
   0x000: b800 114c 2a2b 1212 322a b900 1802 00b8
   0x010: 001e c000 20b7 0023 b1

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu






signature.asc
Description: Message signed with OpenPGP

Bug or expected behaviour?

[Keith Suderman]

Hello,

I have a parent class that defines a static final String and a child class that 
references the String in it's constructor.  Essentially:

class Parent { 
static final String DEFAULT = 'default' 
}
class Child extends Parent {
String value
Child() { this(DEFAULT) }  // Bad type on operand stack
Child(String value) { this.value = value }
}
println new Child().value
 
However, when I try to run the code I get a "java.lang.VerifyError: Bad type on 
operand stack" (see below).  From my understanding this exception is caused 
when a constructor tries to use a variable/field that has not been initialized 
yet; i.e. the `this(DEFAULT)` in the above example.  However, if I qualify the 
DEFAULT with the class name (i.e. `this(Parent.DEFAULT)`) the code works as 
expected.

Similar code in Java works without DEFAULT being qualified with the superclass 
name.  So I am wondering; is this a bug or a design decision that was made 
somewhere/sometime?  

I am using Groovy Version: 2.5.2 JVM: 1.8.0_40 Vendor: Oracle Corporation OS: 
Mac OS X

Cheers,
Keith

Caught: java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
Child.()V @10: invokeinterface
  Reason:
Type uninitializedThis (current frame, stack[2]) is not assignable to 
'java/lang/Object'
  Current Frame:
bci: @10
flags: { flagThisUninit }
locals: { uninitializedThis, 
'[Lorg/codehaus/groovy/runtime/callsite/CallSite;' }
stack: { uninitializedThis, 
'org/codehaus/groovy/runtime/callsite/CallSite', uninitializedThis }
  Bytecode:
0x000: b800 114c 2a2b 1212 322a b900 1802 00b8
0x010: 001e c000 20b7 0023 b1   

Re: bool

[Keith Suderman]

And again, because apparently MacMail is MUCH smarter than I am...

Sending this again because my mail program keeps insisting on changing the 
From: address... apologies if this gets double posted.

-1 on all proposals that introduce new reserved words that do not have a strong 
justification and use case.  The only thing `fin` and `bool` will do is 
potentially conflict with existing variable/method names in programs with 
little other benefit.  One of my biggest pet peeve's with Python is how they 
have polluted the namespace with short names I like to use as variable names 
(dict, list, etc).  Let's not do this with Groovy.

Just my two cents.
Keith

> On Jul 22, 2018, at 4:57 PM, Jennifer Strater  <mailto:jenn.stra...@gmail.com>> wrote:
> 
> Hi mg,
> 
> I also don't like the 'fin' proposal, but I could get behind 'bool'. It's 
> shorter but doesn't lose the meaning. It also makes it easier for people 
> coming from other programming languages.
> 
> Best,
> Jenn
>  <https://twitter.com/codejennerator>  <https://linkedin.com/in/jennstrater>
> 
> On Sun, Jul 22, 2018 at 11:39 PM, MG  <mailto:mg...@arscreat.com>> wrote:
> Hi,
> 
> since things are going so well with my "fin" = "final" proposal, I propose 
> that Groovy support "bool" as a shortcut for "boolean".
> 
> "boolean" is already seeing large scale use by Groovy developers, "bool" 
> instead of "boolean" saves nearly half of the keyword's characters, "bool" is 
> used in C++, it fits better with the also widely used "int", and Groovy 3.0 
> is the ideal opportunity to introduce such language extensions.
> 
> Cheers,
> mg
> 
> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu <mailto:suder...@cs.vassar.edu>






--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu <mailto:suder...@cs.vassar.edu>

Re: bool

[Keith Suderman]

Sending this again because my mail program keeps insisting on changing the 
From: address... apologies if this gets double posted.

-1 on all proposals that introduce new reserved words that do not have a strong 
justification and use case.  The only thing `fin` and `bool` will do is 
potentially conflict with existing variable/method names in programs with 
little other benefit.  One of my biggest pet peeve's with Python is how they 
have polluted the namespace with short names I like to use as variable names 
(dict, list, etc).  Let's not do this with Groovy.

Just my two cents.
Keith

> On Jul 22, 2018, at 4:57 PM, Jennifer Strater  <mailto:jenn.stra...@gmail.com>> wrote:
> 
> Hi mg,
> 
> I also don't like the 'fin' proposal, but I could get behind 'bool'. It's 
> shorter but doesn't lose the meaning. It also makes it easier for people 
> coming from other programming languages.
> 
> Best,
> Jenn
>  <https://twitter.com/codejennerator>  <https://linkedin.com/in/jennstrater>
> 
> On Sun, Jul 22, 2018 at 11:39 PM, MG  <mailto:mg...@arscreat.com>> wrote:
> Hi,
> 
> since things are going so well with my "fin" = "final" proposal, I propose 
> that Groovy support "bool" as a shortcut for "boolean".
> 
> "boolean" is already seeing large scale use by Groovy developers, "bool" 
> instead of "boolean" saves nearly half of the keyword's characters, "bool" is 
> used in C++, it fits better with the also widely used "int", and Groovy 3.0 
> is the ideal opportunity to introduce such language extensions.
> 
> Cheers,
> mg
> 
> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu <mailto:suder...@cs.vassar.edu>






--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: bool

[Keith Suderman]

-1 on all proposals that introduce new keywords that do not have a strong 
justification and use case.  The only thing `fin` and `bool` will do is 
potentially conflict with existing variable/method names in programs with 
little other benefit.  One of my biggest pet peeve's with Python is how they 
have polluted the namespace with short names I typically use as variable names 
(dict, list, etc).  Let's not do this with Groovy.

Just my two cents.
Keith

> On Jul 22, 2018, at 4:57 PM, Jennifer Strater  wrote:
> 
> Hi mg,
> 
> I also don't like the 'fin' proposal, but I could get behind 'bool'. It's 
> shorter but doesn't lose the meaning. It also makes it easier for people 
> coming from other programming languages.
> 
> Best,
> Jenn
>  <https://twitter.com/codejennerator>  <https://linkedin.com/in/jennstrater>
> 
> On Sun, Jul 22, 2018 at 11:39 PM, MG  <mailto:mg...@arscreat.com>> wrote:
> Hi,
> 
> since things are going so well with my "fin" = "final" proposal, I propose 
> that Groovy support "bool" as a shortcut for "boolean".
> 
> "boolean" is already seeing large scale use by Groovy developers, "bool" 
> instead of "boolean" saves nearly half of the keyword's characters, "bool" is 
> used in C++, it fits better with the also widely used "int", and Groovy 3.0 
> is the ideal opportunity to introduce such language extensions.
> 
> Cheers,
> mg
> 
> 
> 
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

[Keith Suderman]

-1

I'm going to rain on the parade.  I like consistent versioning and skipping 
versions is not consistent.  Why not 2.999 or 2.999 then?

- Keith


> On May 20, 2018, at 10:01 AM, Cédric Champeau  
> wrote:
> 
> +1 but alternatively, we could just skip 2.6 and go straight to 3.0.
> 
> Le dim. 20 mai 2018 à 15:25, mg  <mailto:mg...@arscreat.com>> a écrit :
> 2.9.0 could make people ask themselves where 2.6/2.7/2.8 went, whereas 2.97 
> is so far from 2.5, that I think people would get that it means more "3.0 
> minus small, but (significant) delta" (i.e. not just an epsilon, as with 
> 2.99, which Russel suggested). Plus the "7" has a mnemonic quality, making it 
> easier for everyone to remember what the main point of this release was...
> 
> (2.9 would be much better than 2.6, though...)
> 
> 
>  Ursprüngliche Nachricht 
> Von: Andres Almiray mailto:aalmi...@gmail.com>>
> Datum: 20.05.18 15:11 (GMT+01:00)
> An: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
> Cc: pa...@asert.com.au <mailto:pa...@asert.com.au>
> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
> 
> I’d suggest to keep it simple, go with 2.9.0. 
> 
> Sent from my primitive Tricorder
> 
> On 20 May 2018, at 21:50, mg mailto:mg...@arscreat.com>> 
> wrote:
> 
>> What about 2.97 ? Incorporates a JDK 7 reference, and is not too close to 
>> 3.0 (Bugfixes could go into 2.97.1 etc..., so the "7" could be kept).
>> 
>>  Ursprüngliche Nachricht 
>> Von: Russel Winder mailto:rus...@winder.org.uk>>
>> Datum: 20.05.18 12:26 (GMT+01:00)
>> An: pa...@asert.com.au <mailto:pa...@asert.com.au>, dev@groovy.apache.org 
>> <mailto:dev@groovy.apache.org>
>> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
>> 
>> On Sun, 2018-05-20 at 13:58 +1000, Paul King wrote:
>> > Hi,
>> > 
>> > I was wondering what people thought about renumbering Groovy 2.6 to 2.9.
>> > It is only a subtle change but I think better conveys that it isn't a small
>> > step up
>> > from 2.5 but rather something just a bit short of 3.
>> > 
>> 
>> If it is to be the last 2.X release why not 2.99 to make it more "in your
>> face"?
>> 
>> -- 
>> Russel.
>> ==
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk <http://www.russel.org.uk/>



--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [GEP]Lazy evaluation for Groovy 3

[Keith Suderman]

+1 for the concept.

-1 for using parenthesis.  As Andrew says, this introduces new behaviour for 
parenthesis that I think violates the principle of least surprise.

Keith

> On Mar 17, 2018, at 1:54 PM, Andrew Bayer  <mailto:andrew.ba...@gmail.com>> wrote:
> 
> Agreed - I don’t think this actually provides much, if any, real value, is 
> syntactically confusing, and feels like it could cause some problems with 
> existing code that assumes parentheses aren’t going to result in new behavior.
> 
> A.
> 
> On Sat, Mar 17, 2018 at 8:35 AM Cédric Champeau  <mailto:cedric.champ...@gmail.com>> wrote:
> -1, I also think this is confusing.
> 
> 2018-03-17 13:30 GMT+01:00 Guillaume Laforge  <mailto:glafo...@gmail.com>>:
> I also find it confusing, in particular because it's not obvious, and there's 
> some redundancy already with @Lazy (and Paolo has a good point as well as 
> using closures are somewhat of a palliative as well)
> Perhaps we could think of ways to further improve / expand @Lazy perhaps?
> (rather than inventing something new / additional)
> 
> On Sat, Mar 17, 2018 at 12:01 PM, Paolo Di Tommaso  <mailto:paolo.ditomm...@gmail.com>> wrote:
> Frankly I found this confusing, it looks to me that the same concept can be 
> implemented just using a closure. 
> 
> 
> p
> 
> On Sat, Mar 17, 2018 at 9:08 AM, Daniel.Sun  <mailto:sun...@apache.org>> wrote:
> Hi Guillaume,
> 
> I planed to generate proxy for lazy evaluation, so even if the reference of
> object is accessed, evaluation will not be triggered either, which is
> different from @Lazy
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html 
> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
> 
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> 
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+ 
> <https://plus.google.com/u/0/114130972232398734985/posts>



--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: Groovy Champions proposal feedback

[Keith Suderman]

I may as well chip in my $0.00 worth.

I like the concept,  that it will be retroactive, and will consider more than 
just code contributions.

I also think the chosen name should be professions looking/sounding and not be 
"cutesy".  Therefore my preference(s) would be:

1. Groovy Champion (to be as close as possible to Java Champion)
2. Groovy Star (due to the logo tie-in)
3. Groovy MVP

Anyone confusing "Most Valuable Player" with "Minimum Viable Product" needs to 
get out and watch more sports ;-)

- Keith

> On Feb 13, 2018, at 4:58 AM, Paul King  wrote:
> 
> 
> Hi everyone,
> 
> A few of us have had various discussions (in fact over many years)
> about having a recognition scheme similar to Java Champions,
> perhaps called "Groovy Champions" or "Apache Groovy Champions"
> or something else entirely if we think of a better name.
> 
> I think the idea has always been to recognize contribution within the
> whole Groovy ecosystem not just the Apache Groovy project. The many
> tens of projects within the ecosystem are often where many ideas come
> from for the project's future evolution and also where future contributors
> may arise. And in any case, Groovy has always been about making
> coding productive and fun and we should celebrate that widely!
> 
> There are various questions to ask like should such a scheme
> be formally coordinated by the project/by Apache or should it be run as a
> community-driven unsanctioned activity and if so what guidelines should
> be in place. Also, there are many details like how will the scheme operate?
> How are new members elected? Is it a lifetime recognition or is there
> an "emeritus" status? And so forth. Java Champions vote themselves
> on new champions and the recognition has a lifetime status for instance.
> if we progress this idea, we'd need to make that all clear but that isn't
> the purpose of this email - we need to first decide if we like the idea.
> 
> Even if we like the idea, there are still some hurdles to step through.
> We've already sought some informal feedback from other parts of
> Apache and other projects within the Groovy Ecosystem and we'll
> likely need further discussions. We want something that embraces
> the whole community but fits in with Apache project governance
> around trademarks/branding.
> 
> So, the first question is: are we as a project in favor of such a scheme?
> 
> Cheers, Paul.

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: Remembering imports between script invocations

[Keith Suderman]

Import statements are really just shortcuts to tell the compiler how to resolve 
class names so there is nothing to "remember" between invocations, that is, 
nothing gets added to the Binding.

I am not familiar with the javax.script API, but I suspect that you will have 
to provide your own ScriptEngine implementation as you will need to modify the 
CompilerConfiguration object the GroovyShell is using to compile the Groovy 
code.  For example:

CompilerConfiguration configuration = new CompilerConfiguration()
GroovyShell compiler = new GroovyShell(configuration)
println compiler.evaluate('json=\'{"foo":"bar"}\'')
println compiler.evaluate("groovy.json.JsonOutput.prettyPrint(json)")

/* Fails: MissingPropertyException */
/* println compiler.evaluate("JsonOutput.prettyPrint(json)") */

ImportCustomizer imports = new ImportCustomizer()
imports.addStarImports("groovy.json")
configuration.addCompilationCustomizers(imports)
// Works, the compiler can now resolve groovy.json.JsonOutput
println compiler.evaluate("JsonOutput.prettyPrint(json)")

The difficult part will be "hooking" into the compiler to know when an import 
statement is used so you can update your CompilerConfiguration object.  I am 
sure the really clever programmers here could come up with some sort of AST 
transform that would do this.  However, depending on what you are allowed to do 
one option would be to tell your users that you have a "Groovy DSL" and then 
implement an "include" method that users would use to "import" Java packages.

println eval('json=\'{"foo":"bar"}\'')
println eval('include "groovy.json"')
println eval('JsonOutput.prettyPrint(json)')

Object eval(String code) {
Script script = compiler.parse(code)
ExpandoMetaClass metaClass = new ExpandoMetaClass(script.class, false)
metaClass.include = { String name ->
ImportCustomizer includes = new ImportCustomizer()
includes.addStarImports(name)
configuration.addCompilationCustomizers(includes)
"Imported $name"
}
metaClass.initialize()
script.metaClass = metaClass
script.run()
}

Hopefully that gives you some ideas.

Cheers,
Keith

> On Feb 8, 2018, at 3:47 PM, David Ekholm  wrote:
> 
> How do I do that via the javax.script API?
> 
> Even if this is possible via the javax.script API, chances are that a user 
> wishes to ad-hoc add another import, but as they are forgotten between script 
> invocations, it makes it hard to use Groovy to interactively create, say a 
> Swing or JavaFX UI one line at a time. With BeanShell, the user can add the 
> needed imports, execute that "script" and then continue to refer to the 
> imported classes in the following script invocations. Making Groovy remember 
> imports would make it behave in as nice fashion as the new JShell tool in 
> Java 9. JShell unfortunately cannot run embedded via the javax.script API :-(
> 
> Regards
> /David
> 
>> On 8 Feb 2018, at 21:34, eric.mil...@thomsonreuters.com 
>> <mailto:eric.mil...@thomsonreuters.com> wrote:
>> 
>> You can add all the imports you want to your compiler configuration and they 
>> will be consistently available for all scripts.
>>  
>> From: David Ekholm [mailto:da...@jalbum.net <mailto:da...@jalbum.net>] 
>> Sent: Thursday, February 08, 2018 2:12 PM
>> To: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
>> Subject: Remembering imports between script invocations 
>>  
>> We're considering supporting Groovy as an additional scripting language to 
>> our web gallery software jAlbum (http://jalbum.net 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__jalbum.net&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=39n_uU4e7-n_s_WwrNC_8tQYLfhWKgmT_dDWwJw8ctA&s=jGwsu2zf5Pm3kG3GKLFFxalyi30aoXq_-izsMrEy_iQ&e=>),
>>  but one aspect bugs me: It doesn't seem like import statements are 
>> remembered between script invocations. This makes it far harder to use 
>> Groovy to prototype UIs within jAlbum's scripting console than for instance 
>> BeanShell (using the javax.script API). We currently support the slow 
>> BeanShell scripting language and JavaScript. BeanShell behaves well in this 
>> regard, remembering earlier imported packages between script invocations. 
>> Can this be added to Groovy or is there some API flag we can set?
>>  
>> Regards
>> /David, jAlbum founder and client lead developer.
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: New syntax explosion

[Keith Suderman]

I'm glad I'm not the only.  I've been keeping silent because I'm just a stodgy 
old fart that doesn't like change, but it does seem like there have been 
several syntax changes with little to no discussion, at least here on the dev 
list, and no pressing use cases to justify the changes.  If a certain construct 
is anticipated in Java it makes sense to be forward looking and provided 
something similar, otherwise my concern is that syntax will be introduced that 
will be incompatible with future changes to Java.

Cheers,
Keith


> On Oct 5, 2017, at 2:47 PM, Graeme Rocher  wrote:
> 
> I agree. I'm not keen on if/switch on the right hand side of
> assignments at all and a??.b.c is very obscure
> 
> On Thu, Oct 5, 2017 at 8:01 PM,   wrote:
>> Before Groovy 2.6 and 3.0 are released, will there be a review of the syntax
>> additions for inclusion in the final release?  I get "!in" and
>> "!instanceof".  However, I'm am getting the feeling of "Kitchen Sink" or
>> "just because we can" on recent additions to the parser.  I'm not seeing any
>> of the new syntax adding something I can't get already with reasonably
>> succinct code:
>> 
>> 
>> 
>> `foo?['bar']` is just `foo?.getAt('bar')`
>> 
>> 
>> 
>> `a === b` is just `a.is(b)`
>> 
>> 
>> 
>> `a ?= b` is just `if (!a) a = b`
>> 
>> 
>> 
>> `a??.b.c.` is just `a?.b?.c`
>> 
>> 
>> 
>> 'def a = if (x) b else c` is just `def a = x ? b : c`
>> 
>> 
>> 
>> `def a = switch (x) { case 'b': b; break; case 'c': c; break; }` (or
>> whatever has been proposed) is just `def a = { switch(x) { ... } )()`
>> 
>> 
>> 
>> These last two really bother me because statements and expressions have a
>> distinct meaning in the language and now the meaning is blurred quite
>> completely.  Why is all of this new syntax necessary?  Isn't it enough to
>> have support for Java array init and lambdas now?
>> 
>> 
>> 
>> 
>> 
>> All these new syntax options are making it difficult to entice fellow Java
>> programmers around the office into using Groovy because it is Java plus a
>> *few* very convenient additons.  I almost want to be able to turn off some
>> of these additions so the compiler errors on them.
>> 
>> 
>> 
>> Eric Milles
>> Lead Software Engineer
>> 
>> Thomson Reuters
>> 
>> Email: eric.mil...@thomsonreuters.com
>> 
>> Phone: 651-848-7040
>> 
>> 
> 
> 
> 
> -- 
> Graeme Rocher

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [VOTE] Release Apache Groovy 2.4.12

[Keith Suderman]

+1

Built the sources.zip

> On Jun 21, 2017, at 6:15 AM, Paul King  wrote:
> 
> 
> Dear community,
> 
> I am happy to start the VOTE thread for a Groovy 2.4.12 release!
> 
> This release includes 16 bug fixes/improvements as outlined in the changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340472
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340472>
> 
> Tag: 
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_12
>  
> <https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_12>
> Tag commit id: 731d4daa78b9cd32bea724d2d651aa1164eef6cc
> 
> The artifacts to be voted on are located as follows (r20140).
> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.4.12/sources 
> <https://dist.apache.org/repos/dist/dev/groovy/2.4.12/sources>
> Convenience binaries: 
> https://dist.apache.org/repos/dist/dev/groovy/2.4.12/distribution 
> <https://dist.apache.org/repos/dist/dev/groovy/2.4.12/distribution>
> 
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS 
> <https://dist.apache.org/repos/dist/dev/groovy/KEYS>
> 
> Please vote on releasing this package as Apache Groovy 2.4.12.
> 
> The vote is open for the next 72 hours and passes if a majority of at least 
> three +1 PMC votes are cast.
> 
> [ ] +1 Release Apache Groovy 2.4.12
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.4.12 because...
> 
> Here is my vote:
> 
> +1 (binding)
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [VOTE] Release Apache Groovy 2.4.11 (take 2)

[Keith Suderman]

he DirtyCheckable 
> trait [3].  Same tests pass with 2.4.10.  Lack of knowledge in this area so 
> thus the neutral vote instead of -1.
> 
> [1] 
> https://github.com/apache/groovy/commit/3ab66db22e59baf69aa2977c838881f2e93d16bc
>  
> <https://github.com/apache/groovy/commit/3ab66db22e59baf69aa2977c838881f2e93d16bc>
> 
> [2] just a sample, but all failures seem to be related to the DirtyCheckable 
> trait
> 
> java.lang.ExceptionInInitializerError
> 
> Caused by: groovy.lang.MissingMethodException: No signature of method: static 
> org.grails.datastore.mapping.dirty.checking.DirtyCheckable.$static$init$org_grails_datastore_mapping_dirty_checking_DirtyCheckable__DIRTY_CLASS_MARKER()
>  is applicable for argument types: (java.lang.Class) values: [class 
> org.grails.plugins.web.rest.re 
> <http://org.grails.plugins.web.rest.re/>nder.hal.Product]
>   at 
> 
> [3] 
> https://github.com/grails/grails-data-mapping/blob/4bbba4a20d180244bd1f06e226879e50c36a92c7/grails-datastore-core/src/main/groovy/org/grails/datastore/mapping/dirty/checking/DirtyCheckable.groovy
>  
> <https://github.com/grails/grails-data-mapping/blob/4bbba4a20d180244bd1f06e226879e50c36a92c7/grails-datastore-core/src/main/groovy/org/grails/datastore/mapping/dirty/checking/DirtyCheckable.groovy>
> 
> On Mon, Apr 24, 2017 at 3:09 PM, Paul King  <mailto:pa...@asert.com.au>> wrote:
> Dear community,
> 
> I am happy to start the VOTE thread for a Groovy 2.4.11 release!
> 
> This release includes 11 bug fixes/improvements as outlined in the changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340047
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340047>
> 
> Tag: 
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_11
>  
> <https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_11>
> Tag commit id: 76fece1ebb942eccc0af291932bc2a33fd7946c7
> 
> The artifacts to be voted on are located as follows (r19245).
> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.4.11/sources 
> <https://dist.apache.org/repos/dist/dev/groovy/2.4.11/sources>
> Convenience binaries: 
> https://dist.apache.org/repos/dist/dev/groovy/2.4.11/distribution 
> <https://dist.apache.org/repos/dist/dev/groovy/2.4.11/distribution>
> 
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS 
> <https://dist.apache.org/repos/dist/dev/groovy/KEYS>
> 
> Please vote on releasing this package as Apache Groovy 2.4.11.
> 
> The vote is open for the next 72 hours and passes if a majority of at least 
> three +1 PMC votes are cast.
> 
> [ ] +1 Release Apache Groovy 2.4.11
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.4.11 because...
> 
> Here is my vote:
> 
> +1 (binding)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> 
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+ 
> <https://plus.google.com/u/0/114130972232398734985/posts>
--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [VOTE] Release Apache Groovy 2.4.11

[Keith Suderman]

+1 

Builds. Runs.  All tests pass.  Took a quick look at the documentation and all 
looks good.

Keith

> On Apr 25, 2017, at 3:37 AM, Guillaume Laforge  wrote:
> 
> +1 (binding)
> 
> Build, tests, all went fine.
> I played a bit with the Groovy console as well.
> Documentation looks good too.
> Everything looks okay.
> 
> Guillaume
> 
> 
> On Tue, Apr 25, 2017 at 8:20 AM, Graeme Rocher  <mailto:graeme.roc...@gmail.com>> wrote:
> +1 binding
> 
> On Tue, Apr 25, 2017 at 8:13 AM, Jochen Theodorou  <mailto:blackd...@gmx.org>> wrote:
> >
> > +1 binding
> >
> >
> > On 25.04.2017 00:09, Paul King wrote:
> >>
> >> Dear community,
> >>
> >> I am happy to start the VOTE thread for a Groovy 2.4.11 release!
> >>
> >> This release includes 11 bug fixes/improvements as outlined in the
> >> changelog:
> >>
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340047
> >>  
> >> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12340047>
> >>
> >> Tag:
> >>
> >> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_11
> >>  
> >> <https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_11>
> >> Tag commit id: 76fece1ebb942eccc0af291932bc2a33fd7946c7
> >>
> >> The artifacts to be voted on are located as follows (r19245).
> >> Source release:
> >> https://dist.apache.org/repos/dist/dev/groovy/2.4.11/sources 
> >> <https://dist.apache.org/repos/dist/dev/groovy/2.4.11/sources>
> >> Convenience binaries:
> >> https://dist.apache.org/repos/dist/dev/groovy/2.4.11/distribution 
> >> <https://dist.apache.org/repos/dist/dev/groovy/2.4.11/distribution>
> >>
> >> Release artifacts are signed with a key from the following file:
> >> https://dist.apache.org/repos/dist/dev/groovy/KEYS 
> >> <https://dist.apache.org/repos/dist/dev/groovy/KEYS>
> >>
> >> Please vote on releasing this package as Apache Groovy 2.4.11.
> >>
> >> The vote is open for the next 72 hours and passes if a majority of at
> >> least three +1 PMC votes are cast.
> >>
> >> [ ] +1 Release Apache Groovy 2.4.11
> >> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> >> [ ] -1 Do not release Apache Groovy 2.4.11 because...
> >>
> >> Here is my vote:
> >>
> >> +1 (binding)
> >>
> >
> 
> 
> 
> --
> Graeme Rocher
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> 
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+ 
> <https://plus.google.com/u/0/114130972232398734985/posts>
--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: Welcome John Wagenleitner to the Groovy PMC

[Keith Suderman]

Congrats John.  To tell you the truth, I thought you already were a member!


> On Apr 3, 2017, at 9:30 AM, Mario Garcia  wrote:
> 
> Congratulations!!
> 
> On 3 Apr 2017 00:25, "Shil Sinha"  <mailto:shil.si...@gmail.com>> wrote:
> Congratulations John!
> On Sun, Apr 2, 2017 at 8:35 AM Cédric Champeau  <mailto:cedric.champ...@gmail.com>> wrote:
> Congrats and welcome, John!
> 
> 2017-04-02 12:49 GMT+02:00 jim northrop  <mailto:james.b.north...@googlemail.com>>:
> Welcome aboard John! 👍
> 
> Sent from my iPad
> 
> > On 2 Apr 2017, at 11:11, Daniel Sun  > <mailto:realblue...@hotmail.com>> wrote:
> >
> > Congratulations to John :)
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> > --
> > View this message in context: 
> > http://groovy.329449.n5.nabble.com/Welcome-John-Wagenleitner-to-the-Groovy-PMC-tp5739577p5739582.html
> >  
> > <http://groovy.329449.n5.nabble.com/Welcome-John-Wagenleitner-to-the-Groovy-PMC-tp5739577p5739582.html>
> > Sent from the Groovy Dev mailing list archive at Nabble.com.
> 

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: [VOTE] Apache Groovy Roadmap

[Keith Suderman]

I will let the PMC decide on the exact numbering and what goes where.  However;

+1 on getting Macros and Parrot out the door and available in a 2.x compatible 
version as soon as possible.


> On Feb 7, 2017, at 9:59 AM, Jesper Steen Møller  wrote:
> 
> Well, I didn't see many actually object to the contents or order that you 
> suggested, but primarily the numbering. I'll give it another go.
> 
> The vote thread seemed to raise three issues:
> 1) Whether or not to provide the parrot parser as a standalone option ASAP 
> (this is actually quite a bit of work)
> 2) How to best design the semantics of lambda expressions in Groovy
> 3) How to deal with Groovy in JDK9 with or without breaking changes (i.e. 
> still support Groovy 2.x in JDK9 WITHOUT Jigsaw, but only Groovy 3.x WITH 
> Jigsaw, because of indy and new package names, which both break old 
> classfiles and perhaps source).
> 
> If we're very pedantic about semantic versions, we'll have to bump major 
> numbers each time we raise the minimum runtime requirement. But - what if 
> we're less pedantic? We could restate our semantic versioning interpretation 
> to be that the 2.x line will be source code compatible with previous 2.x 
> Groovy sources, but with higher JVM runtime environment requirements.
> I.e. you can still run your old Groovy-compiled classfiles with Groovy 2.x. 
> So they're compatible, you just need a newer runtime...
> As for Parrot: It has been backported to 1.7, and while it would require 
> testing, I can't see the reason for marking it a breaking change.
> 
> I think we should raise these three discussion points as separate threads, 
> and restart the vote, but with two flavours:
> 
> YES-1:
>  - Groovy 2.5: integrates macros and requires Java 7, to be released ASAP, 
> we've been waiting for this for too long 
>  - Groovy 2.6: integrate Parrot, implying backporting Parrot to Java 7 
>  - Groovy 3.0: integrate Jigsaw and drop old callsite caching + use indy. The 
> only version with necessary breaking  changes (we have no choice here) 
>  
> YES-2:
>  - Groovy 3.0: integrates macros and requires Java 7, to be released ASAP, 
> we've been waiting for this for too long 
>  - Groovy 3.1: integrate Parrot, implying backporting Parrot to Java 7 
>  - Groovy 4.0: integrate Jigsaw and drop old callsite caching + use indy. The 
> only version with necessary breaking  changes (we have no choice here) 
> 
> So what will it be: 
>  
>  - [ ] YES-1, I approve the roadmap with the pragmatic stance to 
> compatibility 
>  - [ ] YES-2, I approve the roadmap above with the stricter stance towards 
> compatibility
>  - [ ] NO, I do not approve the roadmap abobe beause... 
>  - [ ] I don't mind, or this goes beyond what I can think of
> 
> In the end, it's for the PMC to decide.
> 
> -Jesper
> 
> 
>> On 7 Feb 2017, at 14.15, Cédric Champeau > > wrote:
>> 
>> The result is that the vote turned into a debate again. I give up :)
>> 
>> 2017-02-07 4:18 GMT+01:00 Daniel Sun > >:
>> Hi Cédric,
>> 
>> 72h has gone.  The result is ?
>> 
>> Cheers,
>> Daniel.Sun
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
>>  
>> 
>> Sent from the Groovy Dev mailing list archive at Nabble.com 
>> .
>> 
> 

Re: [VOTE] Apache Groovy Roadmap

[Keith Suderman]

> On Feb 2, 2017, at 6:47 AM, Jesper Steen Møller  wrote:
> 
> 3. Major numbers should only be used if we mean to break stuff. Parrot 
> shouldn't.


> On Feb 2, 2017, at 10:03 AM, Jochen Theodorou  wrote:
> 
> I would like to have a clarification on 2 things before we really make a new 
> version:
> 
> * is changing to java7 as default a breaking change and requires a new major 
> version? (that implies 3.0 soon and 4.0 for java8 not long after)


The Semantic Version spec states that the major version MUST be incremented if 
the release contains breaking changes, but the inverse is not true, that is, 
the major version can be incremented even if the release does not include 
breaking changes.  I am of the opinion that the inclusion of Parrot + requiring 
Java 7 are big enough developments to warrant an increase in the major version 
even if nothing breaks.

Cheers,
Keith


> 
> Kind regards
> Jesper
> 
>> 
>> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau > > wrote:
>>> Hi guys,
>>> 
>>> There are multiple conversations going on for weeks, and I think they are
>>> going nowhere. We could discuss for months what's the best plan for Groovy,
>>> without releasing anything. Here are the challenges that are waiting for us:
>>> 
>>> 1. release a version of Groovy that integrates Groovy macros
>>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
>>> to smoothly transition to higher requirements (and also, make our devs lives
>>> easier)
>>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>>> drop the old call site caching and use indy Groovy everywhere
>>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>> 
>>> I would like to propose the following plan:
>>> 
>>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>>> for this for too long
>>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>>> changes (we have no choice here)
>>> 
>>> This plan is, I think, a good compromise for all the requirements we have:
>>> backwards compatibility, and making progress and not having too many
>>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>>> us have said, this is incompatible with a soonish release. The drawback is
>>> that Parrot has the risk of being a breaking change (it is, typically if
>>> people implicitly depend on the old parser, which would be bad), so there's
>>> a risk of not following semantic versioning.
>>> 
>>> - [ ] YES, I approve the roadmap above
>>> - [ ] NO, I do not approve the roadmap abobe beause...
>>> - [ ] I don't mind, or this goes beyond what I can think of
>>> 
>>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>> 
>