Sunday, 21 December 2008

JDK 7 language changes - JavaEdge votes!



Given ten language changes, rank them according to priority


The features voted on were:

  • For-each loop over a Map
  • Control over for-each loops (index/remove)
  • List/Map access using []
  • Infer generics on the RHS
  • Multi-catch of exceptions
  • String switch
  • String interpolation
  • Multi line strings
  • Resource management
  • Null handling


Here are the first preference votes:

Adding the second preference votes:

Adding the third preference votes:

Adding the fourth preference votes:

Adding the fifth preference votes:



All votes:


All votes:









Any feedback or thoughts are welcome!


  1. Hi Stephen I really hope some changes make it, but it feels like we're discussing changes for too long now and that Java 7 isn't going to get much features anyway. I think I would appreciate most of these proposals, and even more so closures and properties.

  2. I imagine that there are no people who would comment here and not like to see closures or properties in java.

    Among the changes above I like the null-handling most, and dislike the ones most which could be implemented as API if closures were there (i.e. ARM and enhanced loops).

  3. Great work, Stephen! Thanks!

    However, it unfortunately escapes me why null-handling is so popular. I totally agree with Charles Nutter on this matter. Furthermore, I just don't see any real use case for this ... yet. I mean if you have something like 'Object d = a.?b.?c;' to forego your null-checking then I assume that d is assigned null if any call on the RHS returns null. That'd mean that null is a valid value for some operation on the RHS. That, in my opinion, should rarely be the case or at least dealt with explicitly rather than hiding it in syntax. Furthermore, now you have to deal with d potentially being null. Well, it all seems a bit strange and error-prone to me; not to forget, as Charles mentions, the "problem" you'd have with assignments to primitve types. But if someone comes up with some compelling use cases, I'll reconsider my position ;)

    Cheers, Martin

  4. I agree. Null-handling strikes me as one of the worst features to add to the language. Adding compile-time checking for nullability is one thing, adding a null-handling operation is another. I am strongly against the latter.

  5. O reified generics, where art thou ?

    This is one of the top priority to remove tons of boiler plate codes (think JAX-WS/B/..., think JSF/EL, think Swing/JavaFX data binding ...).

    We do need reified generics with good genericity access to it !

  6. Stephen: We really appreciate that you have the passion and, critically, free time to gather and digest this kind of information for the Java community. I wish we had someone with your passion and free time to complete the Java Time API (JSR 310) for SE 7. Alas, we each have to set priorities.

  7. I see where you guys are coming from. Theoretically it would be better not have a null value at all. Unfortunately we have it, and we have to deal with it.

    In my projects I always try not to produce null values, I procude empty lists or other null-pattern-objects. But what about co-coders? The bigger the project, the likely it is that I will encounter a null value where there should not be one.

    Consider the following example:

    User user = userManager.getUser(userName);
    if (user == null) return;
    History history = user.getHistory();
    if (history == null) return;

    Again, I know, it is bad that there are potential null values here, but I have to deal with it.

    The following code is much more readable and does not loose any information in this case:

    History history = userManager.getUser(userName).?getHistory();
    if (history == null) return;

  8. Hello!

    I will describe my opinion about this changes.
    String switch:
    Hope u will give yours opinion as well.


  9. Null handling:

    For-each loop:

