Do you need closures in Java?

TheServerSide has raised a question about whether closures proposals to be implemented in the Java language are really necessary. In my opinion, I think the Java language must be as it is, because:

  • Generics syntax introduced in Java 1.5 are very difficult to understand and parse when code is read; mixing it with closures will keep the code a little messy;
  • People would prefer to do things in the way they are used to, instead of learning a new construct in the language to implement their tasks (it’s better to focus on code maintenance and readability, after all, code is more read than written);
  • Anonymous-inner classes are far less readable than inner classes, imagine when closures appear in such a code;

So, I think it’s better to maintain the language with the abstractions it already offers and focus on other improvements, like reifiable generics, that is, making generic type information available at runtime. And you? Will you think useful closures on the Java language?

14 Replies to “Do you need closures in Java?”

  1. Anonymous-inner classes are far less readable than inner classes, imagine when closures appear in such a code;

    Using a good indentation I don’t think anonymous inner classes are hard to read at all. Having a swing application as a personal project I’m used to write a lot of code with them.
    The way I imagine closures would, among other things, make the code we do with anonymous inner classes easier to read. Like the delegate keyword does in the C# world.
    But even with this advantage, as I said before I would still stick with Java closureless 😉

  2. Anonymous-inner classes are far less readable than inner classes, imagine when closures appear in such a code;

    Using a good indentation I don’t think anonymous inner classes are hard to read at all. Having a swing application as a personal project I’m used to write a lot of code with them.

    The way I imagine closures would, among other things, make the code we do with anonymous inner classes easier to read. Like the delegate keyword does in the C# world.

    But even with this advantage, as I said before I would still stick with Java closureless 😉

  3. that’s all good news! I’m looking forward to see the next version of this project 🙂
    Btw, regarding JDIC, have you already tried the Java SE 6.0 Desktop classes?
    Something like:

    java.awt.Desktop.getDesktop().open(generatedOutputFile);

  4. that’s all good news! I’m looking forward to see the next version of this project 🙂
    Btw, regarding JDIC, have you already tried the Java SE 6.0 Desktop classes?
    Something like:

    java.awt.Desktop.getDesktop().open(generatedOutputFile);
    
  5. Closures are incredibly usefull in expressing code’s intention and making dsls (and in some other very interesting areas). When mixxed with a collections library that supports them, both gain a lot of leverage.
    Thinking of that, I created this little project called Fluent Java, to enable the easily creating of closures from Interfaces, method names (static or not), some builtin ones and even reusing function concepts from Google Collections, Fork Join CommonsOps and Hamcrest. Not as good as having real closures, but much better than re-writting filters and collectors over and over again (which is the opposite of DRY).

    1. Closures in Java

      Can you show me some real example with closures, generics and bounded wildcards? I favor OO code manutenability and legibility a lot, so I’d like to see this features together on a real software project.

  6. Closures are incredibly usefull in expressing code’s intention and making dsls (and in some other very interesting areas). When mixxed with a collections library that supports them, both gain a lot of leverage.

    Thinking of that, I created this little project called Fluent Java, to enable the easily creating of closures from Interfaces, method names (static or not), some builtin ones and even reusing function concepts from Google Collections, Fork Join CommonsOps and Hamcrest. Not as good as having real closures, but much better than re-writting filters and collectors over and over again (which is the opposite of DRY).

  7. Closures in Java
    Can you show me some real example with closures, generics and bounded wildcards? I favor OO code manutenability and legibility a lot, so I’d like to see this features together on a real software project.

    1. Re: Closures in Java

      This kinda narrowed it down. First of all, in production (aka real world) and with closures, java is out of question (no BGGA example). Next guess would be good old Ruby and Groovy examples. I even found a great smalltalk example. But dynamic language don’t have generics and bounded wildcards. Then you implicitly mentioned you wanted it to be OO. This kinda narrows it down to very few languages: C# and Scala (there are a few obscure other ones, such as Strongtalk, but good luck finding real world examples for that).

      But fortunately, Scala does have its examples on its leading framework: Lift. Found a couple examples on its Active Record implementation (called Mapper). Direct links to its source: line 84 on HasManyThrough.scala, line 458 on CRUDify.scala and line 370 on ProtoUser.scala.

      And lift is in production!

      Enjoy.

  8. Re: Closures in Java
    This kinda narrowed it down. First of all, in production (aka real world) and with closures, java is out of question (no BGGA example). Next guess would be good old Ruby and Groovy examples. I even found a great smalltalk example. But dynamic language don’t have generics and bounded wildcards. Then you implicitly mentioned you wanted it to be OO. This kinda narrows it down to very few languages: C# and Scala (there are a few obscure other ones, such as Strongtalk, but good luck finding real world examples for that).
    But fortunately, Scala does have its examples on its leading framework: Lift. Found a couple examples on its Active Record implementation (called Mapper). Direct links to its source: line 84 on HasManyThrough.scala, line 458 on CRUDify.scala and line 370 on ProtoUser.scala.
    And lift is in production!
    Enjoy.

    1. Re: Closures in Java

      Nice examples, mainly the Scala ones! But I wanna see some real production code with your Java Fluent API, mixing your closures like construct, collections and generics with bounded wildcards. How developers can benefit using your API instead of the default collections ones, regarding code complexity and legibility?

  9. Re: Closures in Java
    Nice examples, mainly the Scala ones! But I wanna see some real production code with your Java Fluent API, mixing your closures like construct, collections and generics with bounded wildcards. How developers can benefit using your API instead of the default collections ones, regarding code complexity and legibility?

    1. Re: Closures in Java

      You wanna see some real production code? So do I 🙂

      This is harder to ask than to actually get it. I’d love to see some real world Hadoop at work examples, or even Cassandra, but people that work on companies that use such bleeding edge high performance applications hardly have the time or are allowed to feed back, more so when using proprietary code they crafted for the company they work in.

      About how people benefit from it, well, the Getting Started page on the project’s wiki give a side by side comparison with what regular verbose java looks like (and does not limit itself in the closure + collection integration, but also encompasses other awkward java apis). I am also blogging from time to time about some other uses of the API.

      It serves good example in showing how this is not java’s inherent fault: it is the builtin util’s fault. This is not new: most projects don’t use java.util.logging, builtin logging facility. Of course, log4j is older than java.util.logging whereas Fluent Java is a lot younger than most other collection libraries out there (including those from java.util).

      But abstract iteration mechanism will be vital to make ForkJoin usable, and therefore make trivial paralelism more accessible. But this is a post in itself.

  10. Re: Closures in Java
    You wanna see some real production code? So do I 🙂
    This is harder to ask than to actually get it. I’d love to see some real world Hadoop at work examples, or even Cassandra, but people that work on companies that use such bleeding edge high performance applications hardly have the time or are allowed to feed back, more so when using proprietary code they crafted for the company they work in.
    About how people benefit from it, well, the Getting Started page on the project’s wiki give a side by side comparison with what regular verbose java looks like (and does not limit itself in the closure + collection integration, but also encompasses other awkward java apis). I am also blogging from time to time about some other uses of the API.
    It serves good example in showing how this is not java’s inherent fault: it is the builtin util’s fault. This is not new: most projects don’t use java.util.logging, builtin logging facility. Of course, log4j is older than java.util.logging whereas Fluent Java is a lot younger than most other collection libraries out there (including those from java.util).
    But abstract iteration mechanism will be vital to make ForkJoin usable, and therefore make trivial paralelism more accessible. But this is a post in itself.

Leave a Reply

Your email address will not be published. Required fields are marked *