groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clark Richey <>
Subject Re: Groovy 3.0
Date Fri, 29 Jan 2016 14:14:45 GMT
That would be very nice to have. 

Sent from my iPhone


Clark Richey

This message and any included attachments are property of FactGem and its
affiliates, and are intended only for the addressee(s). The information
contained herein may include trade secrets or privileged or otherwise
confidential information. Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and
may be unlawful. If you received this message in error, or have reason to
believe you are not authorized to receive it, please promptly delete this
message and notify the sender by e-mail. Thank you.
On Jan 29, 2016, at 03:25, Guillaume Laforge <> wrote:
> The other big item we had envisioned for Groovy 3 were the rewrite of
> the grammar to Antlr v4, so as to support Java 8 language constructs.
>> On Fri, Jan 29, 2016 at 3:13 AM, Jochen Theodorou <> wrote:
>>> On 29.01.2016 00:16, Edinson E. PadrĂ³n U. wrote:
>>> Hi, Guillaume.
>>> In my very humble opinion (and it should be noticed that I'm very far
>>> away to know the Groovy community and language internals as well as you
>>> do), the Python 2.x vs 3.x 'war' was due to mainly a very slow adoption
>>> of the 3.x branch from the different third-party libraries. Even though
>>> the 3.x branch is far better than  its predecessor, the community stuck
>>> with the 2.x branch because of the incompatibility of the libraries
>>> their depended on.
>> I wish you had any idea about how many projects did still use Groovy 1.8 a
>> year ago. It required a CVE for them to even consider changing.
>> [...]
>>> Jigsaw is inevitable and that for itself
>>> require to break backward compatibility.
>> yes and no.. no, because this does not *require* a new MOP, which is all
>> Groovy3 originally was about. Yes, there will be breaking changes... our
>> extension methods will for example have to use proper service provider
>> mechanism, our modules may have to move a few classes because of the
>> almighty no same package for two modules paradigm - just to just name two
>> random items. It would be a good chance though to introduce a new MOP...
>> here I agree.
>> bye Jochen
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet
> Blog:
> Social: @glaforge / Google+

  • Unnamed multipart/alternative (inline, Quoted Printable, 0 bytes)
View raw message