groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <>
Subject Proposed Groovy 3.0 Scope
Date Thu, 17 May 2018 23:59:23 GMT
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.
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

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.
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

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

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
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
(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,

View raw message