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();    

would become ...

String reversed = { 
    String s => 
    new StringBuilder(s).reverse().toString()

[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
  • It might not be: feel free to revise my example – Ryan Delucchi Apr 13 '11 at 18:50
  • 3
    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: baptiste-wicht.com/2010/05/… – Nicole Apr 13 '11 at 20:57
  • is it like C# lambda expression? – Louis Rhys Sep 30 '12 at 5:45

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.


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.

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.

  • 1
    This makes no sense. Closures have nothing to do with threading or mutability. – davidk01 Sep 30 '12 at 2:59
  • They do. Proper closures requires immutability to work with without brain explosions. – permeakra Sep 30 '12 at 5:16
  • No, they don't. A closure is a piece of code that knows about the environment it was created in. That's it. – davidk01 Sep 30 '12 at 7:56
  • 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 1 '12 at 4:26
  • 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 1 '12 at 10:19

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.