« Why Would a Groovy Swing Programmer Need a Matisse-like GUI Builder? | Main | Groovy and (Dynamic Dispatch|Multiple Dispatch|MultiMethods): A Simpler Example »

Closures in Java: Too Much Typeing!

A consensususes has been reached on adding Closures to Java 7. While this is good for Java I'm afraid I may never use it because there is just too much typing. My fingers will get sore typing out all those class names! Either that or my spacebar will break when the IDEs catch up. Let's do a small comparison of some of the samples from the currently proposed Java closures specification and Groovy. First: Java,

{int,int=>int} plus = {int x, int y => x+y};

45 characters and 5 types. Now for groovy:

def plus = {x, y -> x+y};

23 characters, whoops, 22 because the semi-colon is not needed. And only one type (if you count the any-type 'def'), zero if you execute it in a script. Of course the Java version will likely run in less than one hundredth of the time *ducks*.

Comments (5)

You have two compare the number of keystrokes of it takes to define a Java closure to the number of keystrokes it takes to achieve the same goal without using the closures in Java. And yes, it is a relief!

Danno Ferrin [TypeKey Profile Page]:

If someone put a one dollar bill, and a five dollar bill in front of you and told you to take as much money as you wanted, what would you do? Java 6 is the one dollar bill, Java 7 would be the five dollar bill. Or you could jsut take them both and call it Groovy.

There is also an ongoing idea to give Java type inference, so then you could do:

final plus = {int x, int y => x+y};

And we'd still have refactoring IDEs.

Angelo Schneider:

I think you might miss the point about the need/option for declaring the closure types:

A method in some container class might look like this:

List apply({Object,Object=>Object} closure) {
return iterate_over_container_and_apply(this, closure);

Now you call it like this:
cont.apply({Object x, Object y => doSomethingWith(x, y)});

Granted, when I define (and use) this closure I need to specify the closures arguments.

However methods(variables) accepting(storing) closers you likely define rarely. But using you will them quite often (passing a closer to a method etc.).

So bottom line this feature is still a great win!


Danno Ferrin:

My point wasn't that Closures in Java are bad, but that Closures in an optionally typed language like Groovy are much better.

If you need types in your closures in Groovy you can add them. And because of the dynamic dispatch/multimethod support more sensible choices can be coded in for plus of disparate types, whereas in Java you are stuck with the method signature chosen at compile time, i.e. a more appropriate method on the receiver cannot be selected.

Post a comment


This page contains a single entry from the blog posted on April 27, 2007 3:00 PM.

The previous post in this blog was Why Would a Groovy Swing Programmer Need a Matisse-like GUI Builder?.

The next post in this blog is Groovy and (Dynamic Dispatch|Multiple Dispatch|MultiMethods): A Simpler Example.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33