scribbles of the perennial debugger…
Closures in Java… do we need it?
I have been figuring my way into Groovy lately (JSR 241). And one thing that came accross my curiosity is Closures.
Closures are like pointers to a function that you can pass as a parameter. Yup, you read it right, pass the function as a parameter to another function. Other languages does have Closures (using the same name or another). We C# delegates, Groovy closures, and C function pointers.
Perhaps due to my orientation and upbringing as Java-centric developer without ever experiencing Smalltalk, the use and significance of Closures will never be clear to me.
It seems that the general trend in the Java language nowadays is to improve the language. Yes, some of them were very useful in pushing Java forward (when I say Java, I’m referring to the language, not the platform), some are plain useless.
These tuti-fruity enhancements to the language, are, I believe is in response to the relative ease of programming in other development paradigms. Say, .Net, LAMP, or perhaps, RoR. Any old-school Java developers will code and prefer the semantics of the older-Java. So, going back to Closures in Java. There is a silent-but-raging debate whether to include Closures in JDK 7 (and if indeed included, what will be its syntax). Though I have not seen much opposition to it in the web, I would still blurt out my unsolicited view on Closures.
Take the real world. Take the real business cases for example. I don’t think, there isn’t any large or realistic need for it. If any, these can be easily addressed through generalizations. And in the most extreme, inner classes, particularly, anonymous inner classes. Now that would be in extreme. In the real world, were much of the business is produced by the EE world, do you really require closures in your EJB? In Servlets? Or perhaps in you JSPs. How about JDBC? JNI? Can’t really think of any…
I believe that Closures will just be a language-level sweetie, and hence, not really needed at all. Java is statically-typed, OO-driven (yeah, debate me on this) language. Having said this, how would you model Closures? How will you document this? How about exceptions management? Closures will almost certainly ran afoul with your nicely-designed exception routines. What happens to EJB/JTS? What happens to your simple Collections? There is one heck of a large mindset to overcome if we are to support Closures.
You see, Java is everywhere. The cult-status following of Java simply makes it harder to implement new niceties. Yes, new features may be introduced but what percentage of the community uses these. Why not just build a new Language instead of further complicating the existing one. Think of it as JRuby, Groovy or perhaps Jython.
…Java is now open-source. Speaking of just creating a new language from scratch and putting all these from-other-language-envy features, do I smell a fork here?
My simple take on Java Closures: We don’t need Closures in Java. 10 years of SE and the robustness of EE is a sound testament to this. Java is fine, as it is.
And yes, I can survive Groovy too with ever resorting to Closures.
| Print article | This entry was posted by Richard Relos on February 26, 2007 at 1:10 pm, and is filed under F/OSS, Java, Programming. Follow any responses to this post through RSS 2.0. Both comments and pings are currently closed. |
Comments are closed.
about 3 years ago
It’s easy to argue that any language change is unneeded, based on it being possible to do anything in the language already. That’s just a function of Turing completeness.
Language changes are about making it easier to do things that we do already, and making it practical to do things that we avoid already because they’re syntactically impractical.
Generics, for example, were emulable before Java 5 – some people wrote code generators that worked a little like C++ templates. I wrote a small library that provided runtime type checking for collections instead (violating the Liskov Substitution Principle at the time, but nevermind..). Both are poor in comparison to just changing the language to make it more flexible.
So generics make convenient what was impractical before, typed collections.
The foreach loop makes easy what was awkward before. There was no real reason that iterating over an array should look any different to iterating over a collection, but it did, and it doesn’t now.
I hope that the next language changes help in the same way. In general, they seem to, with the exception of inline XML support, which is too specific to a format that will hopefully die. I doubt inline XML support will make it into Java though. Lisp syntax used as data looks so much better than XML or JSON.
Further, I teach new programmers Java, and I have to explain fairly pointless constructs like the anonymous class, when this would be so much simpler:
button.addActionListener
{
frame.dispose();
}
about 3 years ago
Hi Richard,
One concrete case that pops to my mind is listing aggregates (for example, the total of a bill). In a standard app there are dozens of places where the totals should be calculated. You can implement the same interface for each java bean, but what if the model is legacy or shared and that is not an option, or you want to calculate different aggregates (e.g. discount and total), or simply you do not want to impose an interface (getAmount) only to simplify calculations?
I agree that the hype is exaggerated, but I sure have one or two cases waiting for closures. Adding Groovy just for this would make it more complex, not simpler.
about 3 years ago
You lost me at tuti fruiti