groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: Proposed Groovy 3.0 Scope
Date Fri, 18 May 2018 23:54:44 GMT
>From the peanut gallery (top posting as we do here on peanut gallery ;-))

This is a GREAT list of things to do in Groovy 3.0!


On Thu, May 17, 2018 at 4:59 PM, Jesper Steen Møller
<> wrote:
> 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 Themes
> Theme: 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:
> 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:
> There’s also a blog post here:
> 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:
> Did I forget anything?
> Are these themes relevant?
> Should some be deferred?
> 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:
> Kind regards,
> Jesper

View raw message