Sunday, December 28, 2008

The future of Java - Closures

With Java SE 6 recently released, the discussion about what features should be in Dolphin is raging hotter than ever. Perhaps the most intereresting Рand invasive Рproposal is the one for closures. But this is complicated by there actually being two proposals. One is called Closures for the Java Programming Language, by Gilad Brach, Neal Gafter, James Gosling and Peter van der Ah̩ (the BGGA proposal). The other one is called Concise Instance Creation Expressions by Joshua Bloch, Bob Lee and Doug Lea (the CICE proposal). Neither of these two have been finished enough to actually create a JSR for them.

So, what’s the difference and what does it mean for Java programmers all over the world? Well, the CICE version is really just some syntactic sugar for anonymous interface implementations. To get closer to the closure ideal, there is some allowance for making it possible to setting variables in the enclosing scope, but there isn’t really anything in here you couldn’t do with a few clever hacks in the Java compiler. As such, it’s better than nothing, but I will be disappointed if this is all we get.

The BGGA proposal then; this is more ambitious. There is new syntax, new function types, two new reference types (Null and Unreachable). It allows some neat things with using the for keyword in new ways, and will also allow closing over break, return and continue (but not in the general way, since that would equal implementing continuations). This is all good. The new syntax have a shortcut, the looks very much like Ruby code blocks, but there are ways of chaining them that looks actually useful (just look at the with-method in the proposal).

Of course, there are problems with the BGGA proposal too. Not so much in the lack of power, but possibly because it will involve to many new concepts (or new for Java programmers at least), to much new syntax, and it is possible that this isn’t even enough to make the closures really useful.

And this is the real problem with adding closures to Java at this point. I commend what they’re trying to achieve, but I believe it’s to late. Having closures from the beginning will shape the API in ways it’s not possible to do right now. The only way we can get the full benefits of all these new toys would be for Sun to revamp the standard library, adding new versions of most classes and making the old ones softly deprecated. Changing the interfaces will be impossible, so we will haft to get used to referencing java.util.CCollection to get at the new each() internal iterator. And that each is needed. Java needs internal iterators. But that’s another rant.

In conclusion; I’m looking forward to see the end result of these proposals, but I’m very wary of what they will bring too. It is very double edged and it sometimes feels like the Java class library should be ripped out and restarted from scratch. This would remove much cruft and create a new, leaner language. And that language should have full closures and have a class library designed to maxime closure goodness.

Resource: http://java.apress.com/article/407/the-future-of-java-closures

3 comments:

  1. Have you tried any of the closures prototypes yourself, or is this just someone else's opinion recycled?

    ReplyDelete
  2. It's someone opinion, you can see that I've copy from this resource:

    http://java.apress.com/article/407/the-future-of-java-closures

    ReplyDelete
  3. huwaaaaa,,,, gi pusing banget ni!!!!!!!
    aku dapat tugas buat algoritmanya sec^n 2x. trus disatuin dalam kalkulator buattan sendiri juga. hiks,hiks,,, g ngerti!!
    tolong bantuin dong!!
    kasih referensi juga gpp
    plzzzz
    ^_^

    ReplyDelete