Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »



June 6th (afternoon) and 7th (full day) 2012


Copenhagen, Denmark


  • Guillaume Laforge
  • Jochen Theodorou
  • Cédric Champeau
  • Peter Niederwieser


  • possible syntax alignments for the new grammar
  • decide if to make the new MOP for Groovy3, or only the grammar
  • more indy enhancements in final, 2.1?
  • compatibility layer for things like ArrayUtil, old power asserts
    • using modules for that to keep the old classes around
  • "true" named parameters
  • traits
  • stream / lazy / for comprehensions / generators 
  • joint compilation with the Groovy Eclipse compiler
    • also problem of reflection usage which seems to impact Gradle users
  • pattern matching
  • how to better engage the community so as to get more contributions and more active contributors
    • for ex. some kind of bug parade with low-hanging fruits for people to get a foot in the project
  • documentation / specification discussion
  • \@DelegatesTo to define closure delegates (nice for code completion and static analysis) GROOVY-5455
  • further modularity steps
  • static type checking improvements with regards to closure parameter type information
  • changes and/or additions regarding curry / curried
    • see mailing-list dicussion


  • Peter's points for Gradle
    • Joint compilation (7 points)
      • groovyc creates ClassNode from Java source
    • Compile class path (4 points)
      • groovyc creates ClassNode from bytecode (without classloader)
    • Some backwards compatibility (2 points)
      • tester and guaranteed
      • super MOP methods should not user number scheme
      • when runtime classes are moved, keep a delegate in old location
    • Add @DelegatesTo annotation (10 points)
      • nothing else to do!


  • Add @DelegatesTo annotation
    • check with Andrew
    • nice way to help IDEs
    • helpful for documentation
    • could be used from static type checking
    • could support the delegation strategy through a parameter
    • bring on the list
      • in which package?
      • in which version(s)? (2.0.1?)
  • Joint compilation
    • need a (partial) java grammar up-to-date
      • no need for a full one, just for structure and performance
    • import resolution issue
      •  java and groovy resolution different
      • means we also need a CompileUnit (ie. containing the imports)
      • a different import type resolution based on the language (ie. java or/and groovy)
    • experiment in a module
    • target 2.1+
      • and probably not 1.8
  • Compile classpath
    • may help with compilation speed (ie performance)
    • groovyc creates ClassNode from bytecode (without classloader)
    • use ASM to parse the bytecode
    • might solve problems with API JARs like servlet / java-ee where methods don't have a body
    • don't have to load dependencies defined in private fields and methods (example: Spring, Spock-Spring...)
    • target 2.1+
  • Investigate encoding class names in the numbering scheme of super bridge methods
    • but breaks backward-compability already as no Groovy 1.8 and 2.0 programs wouldn't work at all!!!
    • more something for Groovy 3
    • reducing the number of bridge methods we generate
    • investigate if static method calls can be made instead of the dynamic ones
    • currently, not possible for @CompileStatic to not generate all those bridge super$ methods






  • No labels