The topics will range between the next coming versions of Groovy: namely Groovy 1.7 and Groovy 2.0. The main highlights will be the following:
- Modularity of Groovy — Paul King
- Combinator parsers — Guillaume Laforge
- Anonymous Inner Classes / Nested Classes — Jochen Theodorou
- Review Hamlet's GEP 2 - AST Builder Support
- Other potential language/platform topics to be discussed
- The native launcher
- Groovy's web service support
- Triple slashy string or alternative heredocs mechanism
- Assessment of project Coin proposals that might be relevant to Groovy:
- null-safe indexing ? http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
- binary literals, e.g. 0b00100001: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000929.html
- curly-brace collection literals for sets (before inner class/closure usage rules them out?): http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html
- improved exception handling: http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html
- Administrative/build/project issues
- Using Gradle for the build
- DCVS for groovy
- The GEP system
- Fate of JSR-241
- Pattern matching (perhaps too much work to do before 1.7) — Guillaume Laforge
- Discuss the design of a new Meta-Object Protocol
- handling of access to private methods/fields/properties
- general missing property/method handling (order of lookup, what extension points)
- are invokeMethod and get/setProperty on GroovyObject still needed? What was their purpose in the first place and how did they develop?
- How does EMC allow extension to invokeMethod and get/setProperty logics? (see for example http://groovy.codehaus.org/ExpandoMetaClass+-+GroovyObject+Methods) And should that be kept, or is it intelligent to do so?
- How to isolate meta class registries? Is that a good thing, is it not needed? How does for example Ruby handle this?
- How easily give any created and not yet created meta class a change? How to isolate such actions?
- Having more information on call sites
- more uniform method missing path
- various scoping aspects
- lexical or dynamic
- block, class, package, OSGi
- thread-bound or not
- state tracing (stacked changes)
- inheritance of meta-changes
- adaptable to invoke dynamic
- avoid synchronization on data
- relying on immutable data structures
- change retrieval (transactionality?)
- non leaking abstractions for the user
- discovery of meta-changes
- magic package
- Mocking support is lacking and would need an overhaul in 1.7
- Check for coverage support results validity
- Discussion on extended annotations
- Idea of encoding in the form of Strings: would create a script, which could support ranges, closures, regex. Try first with Strings to see how far we can go.
- If such annotations can be reused from Java, what's up with parameter names, field access, etc?
- Two aspects: adding annotations support on the various AST nodes, and how to encode that into bytecode
- Regarding loosening the omission of parens, we've currently got a good compromise on readability
- For Groovy 2.0
- think about shipping some public stable AST interfaces on top of the concrete AST
- allow the quoted identfiers for properties, fields, assignemnts
- allow any character in classes fields, methods
- fix closure naming for method names with spaces
- Long discussions on the characteristics MOP2 should have
- Illustrating advanced corner cases
- AST Nodes to be made proper JavaBeans
- Cleaning / review status of operator overloading
- especially comparisons
- phase, statementsOnly, etc, should be properties on the builder itself
- properties on the Ast Builder itself
- Modularity with Grapes
- Early discussion phase but leveraging existing concepts like grapes and GROOVY-2116 (James Strachan's service registration proposal but enhanced)
- Create a branch for playing with the concept and merge back onto 1_7_X/trunk at some point if successful
- Nice to be able to enable some small bits before 1.7 beta but will depend on speed of creation followed by speed of feedback
- How to stop groovy-all jar from getting "too fat"
- How to evolve GDK without breaking (or at least controlled breakage of) legacy scripts
- How to better position Groovy for use in a wide range of scenarios (e.g. mobile)
- How to allow Groovy ecosystem to blossom by allowing many grapes to be created but without requiring all of them to be bundled
- Proposed changes visible to users
- leverage grape system even for Groovy's GDK (may involve "bundled grapes")
- enhance GroovyStarter/LoaderConfiguration to support --grab on commandline and grab in conf file (see also GROOVY-3215 conf file in Groovy)
- (slightly orthogonal but related change) enhance AST transform support to allow scripts to grab without need for a class or method definition, e.g. "@grab(...) Script" (or replace Script with "this" or something else)
- non-all jar will be much slimmer but conf file will download other jars or at least use other jars in distribution zip
- service registration (GROOVY-2116) but enhanced. Each grape can have a META-INF/services/groovy directory with one or more of the following files
- groovyMethods - list of class files containing normal category methods to be registered at global level
- groovyStaticMethods - list of class files containing static category methods to be registered at global level
- groovyExpandoMethods - list of class files containing expando defns
- groovyAstTransforms - ?? but only transforms that come after grape phase?
- groovyBuilderMetadata - ?? of help to IDEs, e.g. AntBuilder/SwingBuilder
- auto import registration
- runner registration (e.g. easyb runner like testng runner)
- existing grapes can be changed to better handle "service registration"
- gdk (or pieces) will start to have version numbers (how to relate version numbers with corresponding runtime versions?)
- Proposed changes invisible to users
- all-jar will come bundled with (almost?) all current functionality (opportunity to remove deprecated functionality?)
- minor changes to current source structure (but do we move to almost like separate 'modules' and move tests)
- minor changes to build files
- Points to consider
- which parts of GDK to tackle All? All but core? Just some less used parts to start with? Tools?
- granularity of grapes
- "@grab xml" vs "@grab xml.slurper and @grab xml.parser"
- "@grab jmx" vs "@grab jmx.builder"
- names to use?
- potential grapes:
core?, numbers?, strings? bsf, jsr223, sql, xml, jmx, time, date, collections, cli, maps, file, streams, process, threads, templates, regex?, encoding, ant, newify?, googleCollections, jsr203/nio, jodatime, actors, combinators, BigTable?, Scala compiler hooks/Scalify
- list of classes or groovy file
- graceful degradation: jars, poms, OSGi manifest, META-INF/services
- think through implications for various embedded usages of Groovy