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.
Selection pressures on company behaviour
8 hours ago