JDK 7 Language Changes are Coined

Joe Darcy has posted a blog post on the status of project coin. According to Joe there are six proposals for small language changes, which are shortlisted by Sun. I put together an overview with some code samples.

1. Strings in switch by Joe Darcy

String s = ...
switch(s) {
  case "foo":
    processFoo(s);
    break;
}

I really have no feelings about this change whatsoever! It's not a pain for me that it doesn't work right now and I think I won't need it if it's gonna be in JDK 7.

2. Improved Exception Handling for Java by Neal Gafter

try {
    doWork(file);
} catch (final IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

I wrote about how great it would be to have this feature as part of closures. As we all know, sadly, there won't be any closures in JDK 7, however I'm really glad that this part is considered to be in.

3. Automatic Resource Management by Josh Bloch

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
  return br.readLine();
}

As with catching multiple Exceptions at the same time, this is a language change that I would welcome with open arms! On the mailing-list of project coin this proposal caused the most vibrant discussions. Josh Bloch was very open about any type of feedback, even when someone suggested a modifier for cleaning up resources instead of the try statement. That made following the discussion very interesting.

4. Improved Type Inference for Generic Instance Creation by Jeremy Manson

Map<String, List<String>> anagrams = new HashMap<>();

I asked for this in a blog post almost a year ago and it seems as if I have been finally heard. The first thing you might ask when you see this, is why Jeremy Manson proposes new HashMap<>() instead of new HashMap(). In his very well worked out proposal, he indicates, it's a matter of backward compatibility. However, he also mentions it is not impossible to remove the arrow brackets in future versions.

5. Elvis and Other Null-Safe Operators written by Neal Gafter and submitted by Stephen Colebourne

String s = mayBeNull?.toString() ?: "null";
Integer ival = ...;  // may be null
int i = ival ?: -1;  // no NPE from unboxing

The operator ?: is called Elvis, because the question mark looks like the Elvis smiley, as I've learned from the Java Posse mailing-list yesterday. Jokes apart, I like this proposal the more I look at it. However, I've never had problems with adding null checks to my code and I'm not sure if the NPE problem would be solved better with annotations. JSR 303 - Bean Validation, provides a @NotNull annotation, which can be used to define your intend to prevent Null from being passed to your method. I tend to think the language level approach is not suitable here.

6. Simplified Varargs Method Invocation by Bob Lee

Before:

static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
  Callable<String> a, b, c;
    ...
  *// Warning: **"uses unchecked or unsafe operations"*
  return asList(a, b, c);
}

After:

*// Warning: **"enables unsafe generic array creation"*
static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
  Callable<String> a, b, c;
  ...
  return asList(a, b, c);
}

This proposal simply moves the warnings from the invocation of the generified method to the declaration. I know this warning is annoying and it would reduce the number of warnings in your code base, but for me, this has never been a real pain so far.

The project coin mailing-list was flooded with proposals, so if you wonder why Sun chose the afore mentioned here's why:

Sun believes that the proposals are small enough, have favorable estimated reward to effort ratios, and advance the stated criteria of making things programmers do everyday easier or supporting platform changes in JDK 7.

You can really tell that Sun is on a schedule and that there is not a lot of time to gather more ideas. In fact Joe asks in his blog post to continue work on the before mentioned proposals, in the form of prototypes and refinements, instead of sending in new ones.

I've been on the project coin mailing-list since day one and I have to commend Joe on how he is "handling" the list. No offense, but some of the folks sending in proposals should really try to get some writing lessons. My English is not perfect and trying to communicate something subtle as a language change is really hard, but some folks are just not able to produce proper English sentences. Joe did a pretty good job in keeping people like that on a short leash.

The shortlisted proposals almost match with the winners of the poll I conducted a couple of months ago. I think in general they are gonna be very welcome by a broad range of developers. However, the implementation of those proposals is a whole different story. Next week we will know more.