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 12 Next »


Considering our limited human resources and time constraints, it is hard to give definitive and accurate estimates of the milestones we are going to release. Nevertheless, in the following sections, you can learn about the milestones we plan to deliver in the coming weeks and months.

Part of the JSR process, we must produce three key deliverables:

  • RI (Reference Implementation): The RI is the binary distribution of the Groovy Scripting Language which passes the TCK
  • TCK (Test Compatibility Kit): The TCK is a suite of tests, tools and documentation that determines whether or not a Groovy implementation (RI or third-party implementation) complies with the GLS.
  • GLS (Groovy Language Specification): The GLS defines the language's grammar and semantics.

Beta milestones

  • beta-9 (released: mid-january 2005): Last "Groovy Classic" release which supports the JDK 5.0 platform as a running target.
  • beta-10 (released: end of february 2005): It will be the last beta release with the old parser, which will include mostly bug fixes, but also include an early access 'JSR Groovy' parser which will be usable via a configuration flag, so you can try out New Groovy. The markup / builder feature will probably be missing in this EA release of the new parser

JSR milestones

The naming scheme is changing to reflect the work done in the JSR process, and we will adopt the "jsr" tag.

  • jsr-1 (released: April 2005): The first jsr-tagged milestone will contain both old and new parsers. By default, the new parser will be activated, but anybody will be able to move back to the old JSR parser by activating a specific flag. It will be an interim release which allows our users to see what impact the new JSR groovy has.
  • jsr-2 (released: June 2005): The second jsr-tagged milestone was quality-focused. It contained better error reporting and improved compile-time checks.
  • jsr-3 (released: August 2005): The third jsr release focused mainly on bug fixing and closing JIRA issues.
  • jsr-4 (released: November 2005): The fourth jsr release focused primarily on class loading and interdependency issues.
  • jsr-5 (released: for mid-February 2006): The fifth jsr release will focus on scoping improvements as a result of decisions from the GroovyOne meeting.
  • jsr-6 (scheduled for mid-June 2006): The sixth release will incorporate the new proposal replacing the @Property notation for defining attributes and fields.
  • rc-1 (scheduled for late-July 2006): The first release candidate of the Reference Implementation will include MOP and the name resolution improvements.
  • rc-2 (scheduled for early-September 2006): The second release candidate of the Reference Implementation.  This and subsequent release candidate versions will be created as necessary.

Final release

  • groovy-final-1.0 Reference Implementation (scheduled for end of September 2006)
  • TCK (to be defined)
  • GLS (to be defined)

Functionality Roadmap

Here are the various features we would like to implement in the forthcoming releases of Groovy.

Groovy 1.0

Mandatory for 1.0

  • the new Meta-Object Protocol (RC-1)
  • new proposal replacement for @Property (JSR-06)
  • deprecate the old
    Unknown macro: {|}
    closure notation and other deprecated notations like 'property' (JSR-06)

Optional for 1.0 (might be postponed for later versions)

  • old for loop (JSR-06)
  • add methods on numbers for time and duration operations
  • allow optional parentheses for method calls with a map foo a:1, b:2, c:{}
  • allow optional parentheses for constructor calls new Foo a, b or perhaps simply a, b
  • make the groovy shell really interactive (no more 'go'), add ability to save sessions

Groovy 2.0

Project management, build and distribution

  • commit more time to improving the documentation, write tutorials and articles
  • setup a proper continuous integration mechanism
  • improve the test cases and put in place a code coverage report
  • improve the overall performance
  • clean the codebase as much as possible
  • rewrite the build from scratch (custom build, Maven 2...)
  • check latest versions of jars we depend on
  • make groovy-all-*.jar the default deliverable, a groovy-core.jar without GDK + ASM & Antlr jarjared, and a groovy-gdk.jar
  • switch to Subversion

Syntax improvements

  • optional 1.0 changes not implemented (see above)
  • syntax for operator overloading (String operator + (String s)
    Unknown macro: { ... }
  • global use directive
  • syntax for method and properties extensions (DGM / C# extensions: Foo meth(Bar b) extends Integer {}) to use in the scope of the class or script
  • foo ?: "nothing" operator for null checks and default values

Research topics

See whether it's possible to support these concepts on the JVM:

  • Continuation support
  • Tail call recursion

Tools and modules

  • groovydoc (in 1.0): Groovy and Java documentation generation tool
  • Write a JSR-223 module compatible with Java 6 (changes from the RI)
  • Groovy DSL (in 2.0): support for custom dynamic parsing for arbitrary text file (could leverage JParsec with a custom builder)


  • Date, Calendar and Number methods for date and duration support, date.format(), date.iso8601, Thread.startIn( 6.minutes + 5.hours ), etc (if not implemented in the optional 1.0)
  • isTrue (or asBool) / isCase / asType for boolean or type coercion
  • introspection API for IDE support and command-line tools
  • add a way to "cast" / coerce a script to a given interface as in JSR-223
  • full annotation support, at the bytecode level, and check we can define closures as values
  • add coercion for closures to single-method interfaces

Groovy 3.0

Rewrite Groovy from scratch in Groovy

Transition period

We will post notes in that section to ease the transition phase between both pre- and post-jsr parsers. Here is a summary of Migration From Classic to JSR syntax

  • No labels