Hi Jesper, good overview document, thank you & would be great if you could help with Groovy 3.0 :-) I agree that what is needed is progression towards decisions on some key questions... Cheers,mg
PS: Under:"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"there seems to be something missing.... -------- Ursprüngliche Nachricht --------Von: Jesper Steen Møller <[email protected]> Datum: 18.05.18 01:59 (GMT+01:00) An: [email protected] Betreff: Proposed Groovy 3.0 Scope 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.IntroductionSeveral 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.0It’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 GoalsGroovy 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.ThemesFit into Java Platform Module SystemAvoid discontinued JDK calls (i.e. reflection tricks)Leaner Closures (like native lambdas)Cleanup the MOPImprove “copy’n’paste-compatibility” with Java These are expanded in the following sections.Breakdown of Development ThemesTheme: Fit into Java Platform Module SystemChop 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 MOPSee the discussion http://groovy.markmail.org/thread/yxeflplf5sr2wfqpThis 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-examplesThere’s also a blog post here: http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.htmlI’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 JavaThe 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 changesRaw strings - Spiking stage (see GROOVY-8564)Array initialization - Partially done - needs doco changesLambda 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 docoDefault 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 - TBDImproved 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 stepsDecisions, 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
