{ by david linsin }

March 27, 2009

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.

6 comments:

Martin Dobmeier said...

Hey David,

I've got to agree that I had a hard time understanding some of the guys that posted to the coin-dev mailing list. As you know, I'm no native speaker either. Most of the time I just gave up on understanding the various proposals ... from an English language point of view.

Well, but it seems that Sun made up their mind a long time ago as to which proposals will be considered for JDK 7. I don't know, but I'm kind of disappointed with how it all turned out to be. The few proposals that made it on the short list are almost exactly the ones that Joe Darcy blogged about 2 month ago. What a coincidence! The entire thing leaves a bad taste in my mouth because it seems to have been decided long ago. I don't agree with a lot of the proposals that've been made but some of them should have been considered in my opinion ...

Ciao, Martin

Alex Buckley said...

@Martin: I'm a fan of numerous proposals made on the list - binary literals, large arrays, named method parameters. (I won't say they're original since they've been in the Sun bug database since forever.) But the real world demands choices be made, and the submitters of the proposals under consideration are willing and clearly able to implement them.

If you think a particular proposal should receive more consideration, don't complain on a random blog. Join the list and offer support for the proposal. Show how your code would benefit from it. Even better, suggest detailed improvements. Best of all, prototype it.

In other words: DO something.

david said...

martin > The few proposals that made it on the short list are almost exactly the ones that Joe Darcy blogged about 2 month ago. What a coincidence! The entire thing leaves a bad taste in my mouth because it seems to have been decided long ago.

I guess those proposals that you are referring to have been around for quite some time and are already well known to the Java community. Various polls and blogs have been asking for feedback on those proposals and AFAIK the feedback was most of the time positive.

The only downside is the cutback we need to live with, because of the JDK 7 schedule...but I guess that's life (at least for a software developer)

alex Join the list and offer support for the proposal. Show how your code would benefit from it. Even better, suggest detailed improvements. Best of all, prototype it. In other words: DO something.

I totally agree with you on the "do something" part, but joining the list and proposing stuff like the "forget keyword" is of no help for anybody.

I don't think the average joe developer is made for language design. However, if code samples, showing how I think my code would leverage from the proposal helps, I think I might submit some feedback next time.

Alex Buckley said...

@david: You say "I don't think the average joe developer is made for language design." I agree, but *this doesn't stop them trying*. We have 12 years' worth of closed RFEs in the bug database to demonstrate this.

The point of Coin is to go just a little beyond "Hey, I want to be able to write this: ..." which is all a bugs.sun.com RFE asks for. Not as far as requiring an implementation, but far enough to let community members who know what they're doing step up.

One thing that has worked really well is when proposals are critiqued by community members. That feedback and the conversation which often follows is more useful to everyone than when a bugs.sun.com submission is closed with "No. This is a bad idea." I personally hate the null-safe dereference operators ("Elvis") but it comes up over and over; having a discussion in public that's visible for all time is helpful.

Another thing that worked is the centralized discussion. Everyone finally knows where to go to discuss language features. (There was some policing behind the scenes to keep discussion there :-) We can move forward from here, get more formal, require implementations, whatever.

Martin Dobmeier said...

@Alex: I really didn't intend to complain. It's just that I got this first impression. All of a sudden there's this list of 5-6 proposals that should be considered and that's it. It just felt "planned". Sorry, if I'm doing you wrong. I can imagine that evolving a language like Java is a hard job and that you just cannot please everybody. Nevertheless, that was my initial reaction and I don't think you can blame me for that ... even if it was on a random blog. Also, just for the record, I like almost all of the proposals on the short list (still undecided about the null handling operator) and I would be happy to see them in Java 7.

Of course you're right in that if I wanted one or the other proposal to be considered I should participate in the discussion. I'm trying to read through (almost) all the posts to the mailing lists (been a subscriber since day one), but frankly most of the time I just don't feel qualified enough. I shouldn't be so shy probably ...

- Martin

Anonymous said...

Hello,

I like the first two proposals, and specially the multiple catch and I don't really understand the advantage of the lastest.

But I'm unable to undesrtand teh existential reason for the "Elvis and Other Null-Safe Operators"
It is just a shorter ternary operators : "String s = maybeNull!=null?maybeNull.toString():"Null";" do the same job and is more readable.

Thanks for your article.


com_channels

  • mail(dlinsin@gmail.com)
  • jabber(dlinsin@gmail.com)
  • skype(dlinsin)

recent_postings

loading...