Wednesday, May 30, 2007

Closures in Java: Why Bother?

Yes, I know Closures are Cool. All the "cool", "new" dynamic languages, like Ruby (which is actually older than Java, BTW), have them, so if Java is going to be "cool", Java needs closures.

Or does it?

My original title for this entry was "Closures in Java: Lipstick on a Pig?", but I decided against that because I don't want to imply any disdain for Java. I've programmed professionally in everything from IBM mainframe assembler language to (shudder) COBOL to Java to Ruby. I spent most of last year developing websites in Ruby on Rails. I currently develop client and server-side solutions in Java.

Professionally, I can't afford to be a language - or even a language-feature - snob. There are things I used to be able to do in assembler language that I can't do in Java, or even (gasp) Ruby. Do you see me writing proposals to add BALR functionality to the Java language? Of course not. Java is not IBM mainframe assembler language. It was never intended to be.

Nor was it intended to be Ruby. Or Python. Or ML. Or LISP. Or whatever your particular favorite non-Java programming language happens to be.

I wish the Java Powers That Be would leave well enough alone, be happy with the success of Java and the JVM, and stop trying to be Everything To Everybody.

Enough with the inferiority complex, already.

So Java doesn't have first-class functions (which some would say aren't essential for closures, but if you're not going to have first-class functions, why bother?). Big deal. It has a large install-base. It has Tomcat. It has the JVM. It has static typing, which is great if you're into that kind of thing. In short, it has everything you need to develop useful, useable, functional programs.

Could Java be a better language? Probably. But could it be worse? Certainly (yes, I'm talking to you, C++).

So why not just let Java be Java? If you really need first-class functions/blocks/closures, use Smalltalk. Or Ruby. Or Python. Or Lisp. If you really need first-class functions/blocks/closures on the JVM, use Smalltalk/JVM. Or JRuby. Or Jython. Or Armed Bear Common Lisp. Or any of the (astonishingly large) number of non-Java languages that have been implemented to run on the JVM.

Here's a thought: look at how JRuby or Jython implement blocks in Java code, and abstract that code into a new library for Java. Or use the existing Jakarta Commons Functor project. There are enough options available that hacking the language spec beyond recognition and bastardizing a decent language in the name of Keeping Up with the Language Jones-es should not have to be considered the only viable option.

Java is a Turing complete language -- by definition, you can do anything in Java that you can in any other Turing complete language. Which means that adding closures to Java, while an interesting theoretical and mental challenge, is not necessary.

So why bother?


Andres Almiray said...

"Why bother" when Groovy also supports closures...

Unknown said...

Well, besides the inferiority complex of what the other guy is doing (mainly C# 3.0), what are the other options? JRuby, Groovy? Uhmm, nice languages, but they're dynamically typed, and I'm talking about something that will be embraced by the corporate world. Scala? - probably too weird for the corporate world.

Something like the Nice language or MultiJava or eJava would probably be a more natural extension to Java. I highly recommend reading Jonathan Locke's Type enhancer papers at

But JRuby and Groovy are not the answers, for obvious reasons.

Unknown said...

Correction, Groovy isn't exclusively dynamically typed. You can use static typing at your discretion.

That's a pretty broad claim, mark, to say that Groovy or JRuby are not the answers. I'm sure there are situations where you would not want to use them, but there is a large number of use cases that would benefit from languages like these.

Ricky Clarkson said...

Here's why to bother - good programmers are already using closures in Java, but their code is harder to read than it should be.

Unknown said...

Leo, I'm not saying that JRuby or Groovy are not the answers for some programming tasks. I'm saying that Groovy and JRuby are not the answers for some kind of successor to what Java is right now.

It's just not going to happen.

David Rupp said...

@ricky clarkson: "...their code is harder to read than it should be."

Can you elaborate? It sounds like you have some objective standard in mind for what closure-enabled code "should" look like.

Or is this just another way of saying "...their code is harder to read than it could be, if it were written in a language that supported closures natively"? Because neither of the BGGA or CICE proposals has a syntax nearly as nice as, say, Ruby's. I'm afraid the demands of static typing, along with the need to maintain the semantics of keywords like break, continue, et al will always work against an optimally readable syntax for closures in Java. And that's not mentioning the problems of generics, exception handling, annotations...

sanity said...

"Java is a Turing complete language -- by definition, you can do anything in Java that you can in any other Turing complete language. Which means that adding closures to Java, while an interesting theoretical and mental challenge, is not necessary.

So why bother?"

Well, pretty-much every programming language is Turing complete, so by that argument, why bother adding any feature to any language?