In response to Graeme Rocher, whose blog doesn't seem to process comments particularly well.. Graeme said: "Java has been around for a decade now. It has jumped several iterations to Java 5 (with Java 6 coming shortly) and the APIs have progressed hugely. The implications of adding closures would be huge, you would have to go back and revisit ALL the Java APIs. I mean, if closures had been around since the beginning the collections API would be entirely different." I expect there could be some autoboxing to get around the API issue, e.g., a closure that takes no input and gives no return value could be automatically boxed to a Runnable. Ditto for the other one-method interfaces, possibly. It'd certainly be interesting if you could do that for your own interfaces too. insert usual moans about autoboxing Yes, autoboxing adds a bump to the learning curve, but if, when it is understood, it removes complexity when reading and writing code, then it is a good thing. I think the autoboxing feature added in Java 1.5 works well, if you understand its mechanisms, though obviously if generics were able to work with primitive types directly (or appear to), autoboxing would be a lot less useful.
CodeSOD: Counting it All
7 hours ago
2 comments:
I suspect neither you or Graeme read the actual proposed spec, which explains how existing APIs are affected. The short answer is that you probably would change almost no existing APIs due to the closure conversion (section 11). See http://gafter.blogspot.com/2006/09/closures-for-java-version-01.html
Hi Neal,
Just noticed your comment, I didn't realise I had moderation enabled..
I did read the original spec - http://blogs.sun.com/ahe/resource/closures.pdf - but I suppose at the time I found the closure conversion part hard to understand - I was mainly interested in getting at the meat, which was the syntax.
Thanks for pointing out what I missed.
Post a Comment