Discussions about proposed new Java language features have flared up in recent months on the Web. While some language features, such as closures, have a high chance of being implemented in the next version of the JDK, others are of a more experimental nature. In a recent blog post, James Gosling warns of the dangers of debating the merits of proposed language features without an available implementation of the feature under discussion:

What I don't like is debate divorced from experiment and data. Language arguments can get into all sorts of handwaving without building sample implementations.

Since Sun open-sourced the JDK late last year, implementing new language features has become possible: Anyone can download and modify the Java compiler sources to suite an experimental idea. This week, Peter von der Ahé, Sun's Java compiler lead, created a java.net project, the Kitchen Sink Language, to host just such experimental compiler changes. In an interview with Artima, Ahé described the new project's goals:

It was originally James [Gosling]'s idea, and is something he mentioned a while ago when we started talking about open-sourcing the compiler. He wanted to be able to create a place where you could experiment easily with adding various language features. [That way], we can evaluate those features before we decide to propose them for inclusion in the standard through the JCP. When we decide to do something in the JCP, it's almost a done deal, and is often fully developed. So where is the room to experiment? That's exactly what we can do now that the compiler is open-source. We decided to set up a project so that anyone can join in.

Ahé noted that most submissions to the Kitchen Sink Project will at first be compiler patches already submitted from the community:

Some open-source contributors have already posted [compiler] patches. I'd like to see those incorporated on the Kitchen Sink project. Remi Forax has been writing a few patches, for instance: One is implementing two alternate versions of one language feature where you can leave out the type of a local variable, and the other feature ... is a shorter syntax for accessing properties. He was one of the first people with access to the project's site.

Possible submissions to the project are not limited to the language features currently under discussion. Indeed, Ahé noted that any experimental feature can be submitted:

The idea with Kitchen Sink is that you can add any feature you like, and people can look at it and discuss that based on having tried it out rather than just [talking about] abstract specifications.

We want it to be open for everybody to play around, with the only caveat [being] that people need to sign the Sun Contributor Agreement before they commit anything to this project. There are also some restrictions on the main branch. If you want to commit to the main branch, you have to follow certain rules. If you think that those rules are premature for what you want to try out, we encourage you to create a branch within the Kitchen Sink ... where you can create your own experimental features.

If you want to get your [changes] into the main trunk, then there are some restrictions. One of them is that you can disable the feature, that the feature be controlled by an option, and that it is not enabled by default. There are also a few minor rules about code review and what should be in the comments. Again, that's only for the main trunk.

The benefits of the main trunk is that it's going to be Java, unless you add options to the compiler. And it also will probably be a bit higher quality because of our code review requirement. If you have some crazy idea and, for example, want to replace the entire parser to [parse something] that doesn't even look like Java, that's OK. That would be done in a branch of the project.

What do you think of the Kitchen Sink project's goals?