groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: Proposed Groovy 3.0 Scope
Date Tue, 22 May 2018 08:35:57 GMT
Nice list. The other thing worth adding somewhere is toolchain support for
the new Parser.
Tools like Groovydoc is needed I would say. We have some additional tools,
e.g. like Java2Groovy and others which we could then consider.

Cheers, Paul.

On Fri, May 18, 2018 at 9:59 AM, Jesper Steen Møller <>

> *Groovy 3.0 Scope (suggestion)*
> TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears
> that there's little consensus around priorities and scope. I'm suggesting a
> structure for discussing scope and setting priorities. HTH.
> Introduction
> Several strands of Groovy development are going on at the moment, with
> different focus - and in the eyes of a would-be contributor, it’s difficult
> to find the best place to help. So, I’ve taken a step back and tried to get
> an overview.
> This is my proposed laundry list of possible items for Groovy 3.0. It has
> been compiled by watching the dev-list, watching the Java development (8,
> 9, 10, 11…), reading blog posts and being a Groovy and Grails application
> developer since 2012, and listening to the input offered.
> At the outset, it follows the discussion from the Apache Groovy Roadmap
> <>
> thread on the mailing list (from January 2017!)
> I do know that several items are controversial, and I’m not trying to tip
> the scale in any direction. This is just a strawman, we’ll discuss it from
> here.
> Motivation for Groovy 3.0
> It’s 2018: Java is alive again, and Groovy is no longer “ahead but
> compatible”, rather the opposite. We need to address Java 9+ compatibility,
> leverage and augment features in Java 8+, and support newer deployment
> modes, such as lean microservice deployments - and be able to be deployed
> under JPMS.
> Compatibility Goals
> Groovy 3.0 is a breaking change from Groovy 2.x, as it will require Java 8
> or better. There should be no gratuitous incompatibilities, but some are
> required:
>    - A new MOP would likely break compatibility when calling Groovy
>    3-compiled code from a Groovy 2 runtime.
>    - A new MOP could be made compatible when calling Groovy 2-conpiled
>    code from a Groovy 3 runtime.
>    - A new package structure would break compatibility. Adding the new
>    classes as fronts for the old classes (and deprecating those) could help
>    people writing for 2.x, like it is being done right now for CliBuilder.
> I’ve broken the plan into a number of “themes”, in no particular order.
> The idea is to put these into epics in JIRA, and attach individual tasks to
> those.
> Themes
>    - Fit into Java Platform Module System
>    - Avoid discontinued JDK calls (i.e. reflection tricks)
>    - Leaner Closures (like native lambdas)
>    - Cleanup the MOP
>    - Improve “copy’n’paste-compatibility” with Java
> These are expanded in the following sections.
> Breakdown of Development ThemesTheme: Fit into Java Platform Module System
> Chop Groovy up into core and a set of extension modules - and change
> package names accordingly. Perhaps we should even divide into a
> runtime-only and compiler split, to allow for even smaller runtimes.
> If we provide “bridge-APIs” in Groovy 2.x in the new package names, we
> could even allow for compatible code to be written i Groovy 2.5+ which
> would upgrade seamlessy to the Groovy 3 implementation.
> Theme: Avoid discontinued JDK calls (i.e. reflection tricks)
> I actually thought it was worse, but Groovy only uses Unsafe for
> FastStringUtils in the groovy-json-direct subproject.
> We use “illegal” reflection tricks a lot and should migrate this to using
> method handles, as these have been promised to become really illegal in
> future JVM versions.
> Theme: Leaner Closures (native lambdas)
> There has been a lot of discussion around this, but I fear it’s been going
> in circles:
> Groovy’s closures are implemented as (generated) classes, whereas Java’s
> lambdas are implemented in methods. I’m thinking it should be possible to
> make Groovy’s closures leaner by using the same approach as Javas lambdas,
> but without sacrificing the unique features of closures in Groovy, AND
> still retaining their unique features, such as delegation.
> Finally, there was some consideration as to how things are done in
> Painless:
> Java9-module-system-findings-td5749016.html#a5749042
> This need not be tied to the syntax and semantics of Java lambdas, at all.
> See below for the discussion.
> Theme: Indy by default / New MOP
> See the discussion
> This depends on whether or not we want to provide binary compatibility.
> Jochen did work on the new MOP a while ago, present in a branch in the
> repo, as presented here:
> gr8conf/groovy-3-and-the-new-mop-in-examples
> There’s also a blog post here: http://blackdragsview.
> I’m thinking it makes a lot of sense, but I guess it needs to be broken
> down into bite size tasks.
> (See also link above around Painless for some MOP discussion)
> Theme: Improve “copy’n’paste-compatibility” with Java
> The original Java compatibility has been a nice gateway drug for Groovy
> beginners, and is worth considering in a number of cases:
>    - Try with resources - Partially done - needs doco changes
>    - Raw strings - Spiking stage (see GROOVY-8564)
>    - Array initialization - Partially done - needs doco changes
>    - Lambda syntax for closures - Done-ish? (native lambda is enabled
>    only in the static mode for the time being - that is possibly final
>    design). Or we
>    - ‘var’? (alias for `def` with some limitation, only used to declare
>    variable) added in GROOVY-8498, but see GROOVY-8580 and GROOVY-8582.
>    - Method/constructor references - possible in Java syntax, but needs
>    to more lean (AKA native method reference) and needs doco
>    - Default methods in interfaces - done using traits but we should
>    consider native support and we need doco (can’t be called from Java, then,
>    can they?)
>    - Static method in interfaces - TBD
>    - Improved switch syntax changes: might possibly be relevant before
>    3.0 is released (see GROOVY-8584)
> Be aware, this subject is really divisive: Some feel that Java
> compatibility should be a default, others that Groovy’s constructs are much
> more expressive and succinct.
> It has also been suggested Java features added for compatibility should be
> accompanied by a “unidiomatic Groovy”-warning.
> Next steps
> Decisions, that only the committers can really make:
>    1. Did I forget anything?
>    2. Are these themes relevant?
>    3. Should some be deferred?
>    4. So, should be have the discussions now, or defer tem to when/if
>    somebody has implemented them?
> Thanks for reading.
> You can find the document at:
> 1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.
> avsaw5h501ly
> Kind regards,
> Jesper

View raw message