How will closures in Java impact the Java Community?

Question

It is one of the most talked about features planned for Java: Closures. Many of us have been longing for them. Some of us (including I) have grown a bit impatient and have turned to scripting languages to fill the void.

But, once closures have finally arrived to Java: how will they effect the Java Community? Will the advancement of VM-targetted scripting languages slow to a crawl, stay the same, or acclerate? Will people flock to the new closure syntax, thus turning Java code-bases all-around into more functionally structured implementations? Will we only see closures sprinkled in Java throughout? What will be the effect on tool/IDE support? How about performance? And finally, what will it mean for Java's continued adoption, as a language, compared with other languages that are rising in popularity?

To provide an example of one of the latest proposed Java Closure syntax specs:

public interface StringOperation {
   String invoke(String s);
}

// ...

(new StringOperation() {
   public invoke(String s) {
       new StringBuilder(s).reverse().toString();    
   }
}).invoke("abcd");

would become ...

String reversed = { 
    String s => 
    new StringBuilder(s).reverse().toString()
  }.invoke("abcd");

[source: http://tronicek.blogspot.com/2007/12/closures-closure-is-form-of-anonymous_28.html]

The example you post is from many years ago - are you sure it's representative of current proposals? — Daniel Earwicker, Apr 13 '11 at 18:48
I have more or less stopped using Java lately. I still look forward to closures though. — Anto, Apr 13 '11 at 18:57
@Daniel - this is not the current proposal, there seems to be a more current (and very different) one here: http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-of-closures — Nicole, Apr 13 '11 at 20:57

score 4 · Answer 1 · answered Apr 13 '11 at 18:57

I think it will take some time for a lot of 'ordinary' Java developers to get their head around this concept if they're not already familiar with it, but gradually it will ease into regular Java usage, to all our benefit. It would be great if it is embraced as quickly as generics were when Java 5 arrived.

I imagine it won't affect VM targeted scripting languages that much as it's only one advantage of using those that have it.

score 3 · Answer 2 · answered Apr 13 '11 at 19:55

There's a usual cycle that goes with any shiny new tool:

Mass excitement, with a flurry of new users abusing it. This is normal and healthy, as it helps us understand the limitations of the new tool and how it can be used.
More reserved people will neigh-say and put down the early adopters as being foolish
Eventually, the excitement wears off and the early adopters settle in on healthy ways to use the new tool
More reserved people will start to envy the productivity of the people using the new tool, and start adopting it--using the now healthy patterns.

This all takes a couple years to cycle through. It was true of annotations and generics, and it will be true for closures as well.

Impact on scripting language folks:

For languages that support closures, this will help the scripting language writers do their job more efficiently. Since they already know how to use closures, they won't necessarily do crazy things.
For languages that don't support closures, this will be largely ignored.

score 1 · Answer 3 · answered Apr 13 '11 at 18:58

1

Those who relish multi-threaded programming will be able to embed immutable data structures in Java and handle them in a more lisp-like manner without the need to resort to non-sequiters due to the language impedance mismatch between Java and Lisp.

Those who do not use (or understand) any of the above will be able to do things just like they did before.

answered Apr 13 '11 at 18:58

Edwin Buck

489
3
7

1

This makes no sense. Closures have nothing to do with threading or mutability. – Sep 30 '12 at 02:59
They do. Proper closures requires immutability to work with without brain explosions. – permeakra Sep 30 '12 at 05:16
No, they don't. A closure is a piece of code that knows about the environment it was created in. That's it. – Sep 30 '12 at 07:56
@permeakra I think you are using the word proper with extra meaning. Some kinds of proper Java can cause brain explosions, but with a different definition of "proper" that same code is not proper. Closures and immutability are a great combo, especially under multi-threading situations, but you can have one, two or all three without requiring the others. Whether your combo of the day _works_ or _is a good combination_ is more a function of the skill of implementation and language parsimony. – Edwin Buck Oct 01 '12 at 02:55
1

@davidk01 the definition is OK, but when closure has link to mutable variable, its result changes with variable changed. Usually, this is not what one want, but if compiler does not object, the error is almost undetectable. – permeakra Oct 01 '12 at 04:26
@permeakra: Do you know of another definition of a closure? – Oct 01 '12 at 04:56
1

@davidk01 No, I don't. My point is that closures/lambdas work well iff they tied with immutability of catched variables. Otherwise you are in mercy of Tzeentch, and only dedicated worshipers have chances here. – permeakra Oct 01 '12 at 10:19
@permeakra It wasn't the definition of closure that I questioned, it was the definition of "proper". Proper is a funny word, it can mean "compiles", "works", "is easy to maintain", and a lot of other things depending on who uses it. I'm saying that today, without closures, we can do threading and immutability. With closures, you can combine them with treading and immutability to get the combination you want, or you could just replace `Comparator` and not be _required_ to use threading or immutability. Your combination of _proper_ and _required_ is restrictive. – Edwin Buck Oct 01 '12 at 13:52

score 1 · Answer 4 · answered Apr 13 '11 at 19:12

I suspect that people who are familiar with closures will start to use them in application code. They'll avoid them in libraries for a while to maintain backwards compatibility with older versions of Java.

Programmers who are not familiar with closures from other languages will be slow to adopt them in Java.

Generics were adopted quickly when they were introduced to Java partially because of all the warnings that showed up when you upgraded and because of their incorporation into the SDK. This won't be true with closures. It will be harder to find evidence of their existence, so only those who want to use them will use them.

I don't think that development of other JVM scripting languages will stop. Those languages have momentum and a lot of features besides closures. We may however see less new JVM languages as closures was the main impetus for creating new JVM languages.

You should have a look at http://mseifed.blogspot.se/2012/09/closure-implementation-for-java-5-6-and.html I think it is pretty awesome! — mjs, Sep 29 '12 at 21:07

How will closures in Java impact the Java Community?

4 Answers4