Saturday, 15 December 2007

Voting on Java 7 language changes

This year at Javapolis I again looked after the whiteboards. In this post, I'll discuss the results.

Whiteboard results

The whiteboards play an important part at Javapolis in bringing people together to discuss ideas and future trends.

This year, I chose to focus the whiteboard debate around a number of specific topics. This was achieved by having votes on 10 language changes proposals, plus areas for new ideas for Spring, JSF, JavaEE and JavaSE. I'm going to discuss the language change votes here, as the photos of the other boards aren't available yet.

Language change votes

Before the conference started, there were a number of language change proposals floating about, initiated by Neal and Josh at Google. These were discussed in a late night BOF on Thursday, but this was backed up by the votes on the whiteboards.

The full results are available (with more detailed examples), but here is the summary.

The strongest support was for Improving Generics, String Switch and Multi-catch. Attendees were giving a clear 'yes' to these being in Java 7.

The strongest opposition was to Typedef (type aliasing) and Extension methods and chaining. Attendees were giving a clear 'no' to these being in Java 7.

There was some support for Better null handling (with a new operator) and Properties. The balance was slightly against, but not overwhelming.

There was positive support for Using [] to access lists and maps. The balance was definitely in favour, yet there was a large minority against. This was perhaps the most surprising vote. Unfortunately, it wasn't possible to find out why there were so many 'no' votes. My view, is that it is still worth pursuing this for Java 7.


Java being open source isn't going to be enough going forwards - it will also be necessary to provide an open community. Votes and direct feedback like this have a really positive effect, allowing Java's growth to be influenced by real developers and their problems.


  1. Great idea to get some votes, I particularly like the yes, no, or maybe options. How come no vote on closures, what about wild cards?

  2. String switch.. ew. It will become another tool for poor developers who use switch instead of polymorphism.

  3. There should be a feature in the JDK to allow you to generate exe for your platform, that wont require jre or anything but that exe and libraries shipped by default on the OS. when that happens Everyone will be developing in java.

  4. I don't want that trademark-encumbered program-language named "Java" to grow!

    We need something new and unencumbered. You are a dreamer, Steve, if you believe that Sun Microsystems will ever give up its stranglehold and almost totalitarian control over their Java (TM).

    Let Java (TM) be Sun's baby and let us make a complete new backwards-compatible unencumbered and non-GPL'd program-language + managed code technology.

  5. Popularity vote sounds like a bad way to plan for future features. It may be
    good to test the waters, but don't don't hesitate to add something if it is
    actually a good idea.

    I have been using C# 3.0 and the new extension methods feature. I was not happy with the idea at first for the very same reasons enumerated here and elsewhere. However, they have proved to be quite useful to me for adding little utility methods to an external API. A simple example is adding a 'isNullOrEmpty()' method to the final String class. Despite what you may think, it is not too difficult to find and use these extension methods in C#. It is not too difficult to understand where they are coming from (your IDE tells you!)

    Anyway, the clincher for me was the reason for extension methods in the first
    place. They were added in order to implement LINQ -- the .Where() and
    .OrderBy() etc methods are actually extension methods. Think of extension
    methods as just another way of separating your data and implementation.

    If Java can add lambdas/closures, extension methods, type inference, and anonymous types then we are half way to adding a query language like LINQ.

  6. I'm encouraged by the vote results as they seem to reflect my personal opinion as well.

  7. So if improving generics gets us:

    public class MyClass {
    public void process(List list) {...}
    public void process(List list) {...}

    Then would we also get:
    public class MyClass implements Comparable, Comparable
    public int compareTo(Foo foo) {...}
    public int compareTo(Bar bar) {...}

  8. Stephen Colebourne17 December 2007 at 23:16

    @Howard, There was also a vote on closures, but it had less total votes (making the result less valid) -

    @Frank, I'd love to see a new Java-like language, but I suspect it needs a big company to back it for it to be successful.

    @Kevin, Popularity is a guide, and nothing more. Opinions can be changed by communication (that was shown at Javapolis too). Extension methods appear to need a lot of selling/explanation.

    @Chris, You need to ask the new compiler guy at Sun. He's just finishing up a PhD, and he focussed on erasing erasure in his studies.

  9. I find this whiteboard voting approach pretty refreshing. It looks like it prevented feature bloat for the sake of feature bloat.

    Good approach. Keep it up! :-D

  10. Christopher Brown18 December 2007 at 12:58

    How representative is this survey? I would have been interested in participating. All the same, it's good that there are efforts to ensure that any new features are really desired.

    I'm still surprised at these property proposals, and the introduction of the "property" keyword. I don't see what that buys over public member fields. The C# syntax is all that is really needed, as it makes it easy to formally identify a property without a naming convention, and enables encapsulation, validation, and computation of virtual properties, as well as any combination of read/write access. It would allow reflection to differentiate some abitrary non-property "get" or "set" method from a real property. If necessary, an annotation could be added to existing APIs to avoid breaking method names and provide the same reflection semantics.

    Simplified list/map access: yes

    Extension methods: now that we have static import, it could become confusing to have extension methods too. Method hiding rules for conflicts between extension methods and declared methods (imagine an implementation of List that defines "sort" conflicting with a "sort" extension method; when you call list.sort(), what are you calling?).

    String switch: a surprise ; as long as it's just syntax sugar around if...else, I suppose so, but I don't need it.

    Multi-catch: how do you refer to the exception in the catch block for exception-dependent methods?

    Import alias (typedef): surprised me that there's resistance, it's quite handy for Date when dealing with java.sql and java.util...

    - Chris

  11. Runtime Aware Genericity (cf. your instanceof test) is realy a MUST DO for JDK7 !

    When using reflection APIs, genericity is useless at this time : no way to known what is the real parametric class (for instance, unable to dynamically instanciate the real class of a list to add an item tru reflection) !

    What about doing this by defining an annotation for the "genericity parameters" retention scope (runtime, compile time).

    Java collection (List, HashMap, etc) should be enabled by default at runtime retention, while other type such as datawrapper might be compile time only for performance reasons.

    anybody working on such a think for JDK7 ?


  12. Introduce "java.lang.XML" as a first-class datatype.

    Manipulating XML structures in Java should be as easy as it is in many scripting languages (e.g., see the E4X extension to JavaScript). JAXB, JDOM, XMLBeans, etc., are all too cumbersome.


  13. Stephen Colebourne21 December 2007 at 13:46

    @bjb, Since Sun has hired a compiler engineer with a PhD in solving the issues of erasure, it may be that we will see something in that area in Java 7.

    @Ganesh, Native XML support is little talked about because it is little liked. I oppose it for one. There is nothing fundamentally special about XML vs any other datatype. After all, why not support JSON natively? Note that does not mean that there aren't solutions that can help - including closures.

  14. XML "literals with expression holes" such as E4X and VB 9 are extremely useful. VB 9's XML literals are built on top of LINQ-2-XML which gives you all the LINQ query capabilities in addition to just being a much better XML api than the XML DOM. Ugh.

    You're right, you can't just add XML literals and call it done. You need a 'data/query api' which is what I've been longing for in Java since trying out C# 3.0. Then one ought to probably build a LINQ-2-JSON and perhaps even allow JSON literals as well. :)



Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.