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 <[email protected]> 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 > <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 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: 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 > 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 > There’s also a blog post here: 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: > > 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: https://docs.google.com/document/d/ > 1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h. > avsaw5h501ly > > Kind regards, > Jesper > >
