Tentative Roadmap

[glaforge]

Dear Groovy developers,

Now that we have released 1.5, it is time to think about the future of Groovy, by discussing its roadmap.

After some discussions at GDC#4 ( http://docs.codehaus.org/display/GroovyJSR/GDC4+Discussions), on the lists, and elsewhere, we've listed possible improvements and new features.

Jochen and myself compiled a tentative roadmap this weekend, taking these ideas into account and trying to lay them out across potential release numbers.

This is a tentative roadmap.
Certain features can be discussed, whether we do want them or not.
And there's room for moving features from one to another release.
New ideas missing can also be introduced.
So it's still pretty open at the moment.

Note that the roadmap can change across the course of time according to the progress (or lack thereof) we make on the GEPs (Groovy Extension Proposals).
It is not set in stone today, even after our upcoming discussions. The GEPs will drive us through the releases.
It is very important that we try to clearly define what we want to do in the coming releases, and not just commit blindly any cool hacks :-)
We need to have crystal clear scope and semantics for all major features.

First of all, the basic idea: instead of one huge release a year with several betas and RCs, it'd be great if we could make more frequent releases (with a few betas and RCs) every two or three months or so, but containing a lower number of major features. So ideally, we could release 1.6 / 1.x throughout the year, with a bigger 2.0 at then end of next year with a reworked MOP system.

There are three main kind of releases:
- 1.5.x will provide some patches to the 1.5 final release
- 1.6 / 1.x will introduce a few major features at each release depending on the completeness of the GEPs
- and 2.0 will focus on the reworked MetaClass runtime system and will be worked on in parallel to the other 1.x releases.

Ideally, we should try to release 1.5.1 next week, before Christmas, with the current fixes for the Ant builder, the dead lock in the class loader.
And probably a 1.5.2 when we find the concurrency issue we have on parallel environments.

Without further ado, here's the proposed Roadmap.
The GEPs will be there for defining the exact scope of the major features by giving some finer-grained details of the content of the upcoming releases.
I'll publish this roadmap on the JSR wiki.

Groovy Roadmap

Groovy 1.5.1

• Bug fix release
• Deadlock in GroovyClassLoader
• Problem with Ant tasks

Groovy 1.5.2

• Bug fix release
• Concurrency issues (unless it's fixed in 1.5.1)

Groovy 1.6

• Based on JDK 1.5 with Retro* version available for JDK 1.4
• Make sure we can run the unit tests with the retro-weaved jar to ensure compatibility
  
• Annotation definition in Groovy
• Currently, annotations can't be defined in Groovy, only used
  
• Multiple assignment
• GEP
• Define the exact scope of multiple assignment by revisiting the existing GEP page
  

Groovy 1.7

• Upgrade to ASM 3
• if necessary or deemed useful (more efficient bytecode?)
  
• Groovy incremental compiler
• Especially useful for the Eclipse plugin
  
• AST transformations
• GEP
• reuse of annotations or not
• exact scope of those transformations
• pluggable AST transformations for advanced DSL or integration cases
  

Groovy 1.8

• Nested Classes & Anonymous Inner Classes
• GEP
• The exact semantics with relationship to the MOP should be properly defined through a GEP
  

Groovy 1.9

• Upgrade to Antlr 3
• We'll be able to use the tooling support accompanying Antlr 3
• Concurrency features
• GEP
  
• Define what coverage we'd like to bring
• Rollback the iterator features to properly discuss them first
  
• Work on this theme first as a module, and if deemed right, we can bring it back to groovy-core
  

Groovy 2.0

• New MetaClass system
• Benchmark test suites to track progress of performance across releases
  
• GEP
• defining the scope of changes
• describing the new system
• proposals of a more homogeneous system
  
• homogenize categories, EMCs, custom metaclasses
• homogenize the configuration / declaration / convetions
• have per-thread / scoped EMCs (like categories)
• per-module/library metaclasses
  

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

[glaforge]

On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:
> Firstly I would like to thank Mr.G and Jochen for setting up such a
> detailed roadmap.

You're welcome :-)

> Now, I would like to add my opinion about it (opinion that might not
> match exactly the above plan).

At least, it's not in contradiction with the roadmap!

> I do consider that the Groovy language has become "enough" feature
> rich. IMO, the most important aspects for the future of the language
> are now more in terms of usability. I don't think I can come out with
> a nice proposal as you did, but my suggestion would be that the work
> should focus on the following directions:
>
> 1/ fixing bugs related to the 1.5 major release. This will probably
> result in a couple more minor releases.

Agreed, this is what the 1.5.x releases are for.

> 2/ focus on the performance. As discussed at GDC this mostly means
> rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> would definitely see the whole energy of the Groovy people going this
> direction only for the next period.

It's going to be a long process I suspect, as various experiments will
have to be done, lots of discussions, a nice general proposal of what
we really want, etc. So it's something that is going to be done in
parallel to the progress we make in 1.x.

> Probably the only "new" feature that I see as belonging to "usability"
> is the multi-assignment, but this is just a nice to have one, so it
> shouldn't focus on it right away (or at least I wouldn't consider it
> as a strict goal for the next immediate period).

I tried to put certain features at certain milestones, but we can
certainly reorder the priorities.
I've put multiple assignments early in the roadmap because we had
promised them in 1.1/1.5, but as they're certainly not critical, we
can postpone them to a latter release, it's not really critical.

In the new features, there are things which should be discussed for
inclusion or not.
For instance, anonymous inner classes, nested classes and co.
Initially, in the early days of Groovy, we didn't want to support them
because we found them ugly, and closures should be used more to fill
in the gap.
So, it's perhaps a debate we should have as to whether the Groovy
users really want them in the language?

Regarding other features, for instance AST Transformations, we can
already do that today, but in a more convoluted way (through the
Groovy classloader), so it's mainly about making this feature easier
to use. And for the concurrency feature, it could even just be an
additional module, instead of bloating Groovy core with yet another
big feature.

> Hope you don't mind expressing my thoughts here,

On the contrary, thanks for sharing your thoughts!

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com