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 
<http://mail-archives.apache.org/mod_mbox/groovy-dev/201701.mbox/%3ccadqzvmn0a83teneg2op_abmgnaoruhxdulvd7t+npun-vtd...@mail.gmail.com%3e>
 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: 
http://groovy.329449.n5.nabble.com/new-MOP-under-Java9-module-system-findings-td5749016.html#a5749042
 
<http://groovy.329449.n5.nabble.com/new-MOP-under-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 http://groovy.markmail.org/thread/yxeflplf5sr2wfqp 
<http://groovy.markmail.org/thread/yxeflplf5sr2wfqp>
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: 
https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examples 
<https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examples>
There’s also a blog post here: 
http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html
 
<http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html>
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: 
https://docs.google.com/document/d/1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.avsaw5h501ly

Kind regards,
Jesper

Reply via email to