To closure or not to closure
I blogged some thoughts on the direction of Java yesterday and Dario Laverde responded with a lot of interesting thoughts, which got me thinking again about closures. I’ve found myself moving back and forth on whether I want them in Java or not. I often see use cases where a closure is exactly what I want and the alternatives in current Java are really ugly. I know that if I had closures I could express exactly what I want, much more precisely.
But, I inevitably compare to generics. I really like generics when using APIs as they give you a much more precise interface. I don’t particularly enjoy the implementation side of the API, particularly when you hit the frustrating “Wall of Erasure”. I think on balance, I could do without them (in erased form). The annoyance of using them is too high given the (relatively small) benefits of type precision.
Closures, especially the control abstraction aspects, have the power to really transform the code we write and look at every day. I know some of those transformations would be really helpful, but I worry that like generics, in other fairly common circumstances they’ll be really ugly and hard to understand. And then I think that maybe it’s just too much for Java and we should use a different language instead if we need that power.
In any case, I think from a language perspective, this is the biggest question before us in the Java community and the Java Modules in JSR 277/294 are the biggest library question. Both of these stand to have a huge impact on Java but its still unclear whether that impact will be a net positive or negative.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
As the discussion usually gets hot on whether or not to add closures to Java, I think, there is no need to think about the closures proposal as final (or BGGA as the only one). Stephen Colebourne actually made a note, that the proposals consist of a bundle of features, which not necessarily have to get into Java at once or in full. Actually, our FCM+JCA proposal does a major split between closures in general and control statements by having two separate proposals in the first place. FCM itself has several aspects, that have similar objectives but can be seen separately.
Maybe, it needs the JSR to find out the single features, their impact, their benefits, and whether or not and which of them should find their way into Java. I think we agree that closures would give quite a lot of flexibility and would make some painful programming patterns go away. It’s just a matter of how far to go.
We should fix the problems in generics before moving on to more features. Specifically, better type inference and NO MORE ERASURE. I am sick and tired of manually passing an extra Class argument to manually remember the type. Passing around Class objects adds noise and complexity.
I would love it if Java got closures. Our code makes extensive use of continuations and similar patterns, and moving some of that API to closures would dramatically simplify things.
But, I am also a huge fan of generics, and think any feature that moves bugs from runtime to compile time is worth its weight in gold.
Which is also why I’m hugely against auto-boxing, which does the opposite, and would love to see a JSR that simply reads “Remove auto-boxing in its entirety from the Java language in JDK 7.”
Autoboxing wouldn’t be so bad if its behavior wasn’t different from the primitive types. Specifically its a little ridiculous to me that an Number[] a can throw a runtimeexception acessing it when a int[] can’t (NullPointerException). The primitive/object value separation that is at the root of the type system says that a primitive can’t have a null value, and this propagates to all the types. However the opposite situation isn’t satisfactory either, (a null value suddenly becomes 0). I actually am thinking that there is no global solution. People that advocate the Maybe Monad and similar stratagems are misguided in my view since that is just pushing the problem back (useful if there is no difference but mostly just wrong).
I would love closures but I’m not sure closures would be truly appreciated by themselves in Java because Java was not designed to be very “functional” (paradigm, not usefulness). That is, Java is set quite deep in the imperative/OO camp.
The primitive/object separation doesn’t come from having a “null”. Ruby, for instance, has “nil” (a “null singleton object”) and does not (outwardly) distinguish between primatives and other objects. The problem, unfortunately, comes from the very core of Java… I am currently using Scala which removes the int/Integer separation (or rather, lets the compiler do the work but, in a more natural and consistent manner than autoboxing in Java.) Using the Option (“Maybe monad”) in Scala makes me hope I never have to touch null again. The Nice programming language (targets the JVM) offered complete “maybe” checking natively as well–I believe, directly around, null.