>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! Thanks, Roman. On Thu, May 17, 2018 at 4:59 PM, Jesper Steen Møller <jes...@selskabet.org> 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: > 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: > > 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 >
