Skip to Content

Closures are now officially announced as probably becoming part of the Java language. Here are a few links about that: 

If one reads the comments of the previously mentioned blogs one gets a quite polarized view. Some people vote enthusiasticly for it and others are strongly against it. What frightens me a bit is the opinion of the initiators who say “Either people understand closures or they don’t like it”. Since I did not find a proof for that I believe that the authors take the critics somewhat easy. Or, to take it less kindly: the authors have no striking arguments to the critics, so they blame the criticizers to not understand the thing.

I must admit that I have very mixed feelings about introducing closures into Java. I did not work with a language with full support for closures yet (if you do not count C as one of them; but when working with it I did not use function pointers widely). So I could as well be blamed as someone who do not understand closures. The following may be read in the light of that.

Amongst my major concerns are readability and maintainability. The former can be due to lack of experience although I work with anonymous classes quite a bit (but I do not like them very much and try to avoid them as far as I can for the sake of readability). On the other hand, what I love with Java is the consequent implemntation of the famous Einstein words “Make it as simple as possible, but no simpler”. As is pointed out eg. in “The psychology of computer programming” by Gerald M. Weinberg, the simplicity of a language is a key for its successful use. I do not think that additional language constructs as the proposed ones are adding simplicity and clarity, especially if the plans come true that exisitng keywords depend in their meaning on the context. Adding new keywords instead won’t simplify the language either. The latter objection might be more serious and is not completely decoupled from the former. There are two problems here: the first is the defining context which can be manipulated. This opens the possibility to have context on local variables which in my opinion should be restricted to instance variables. Lets assume having two closures defined in the same context. In that case the outcome of each closure call can depend on the outcome of another closure call depending on the state of the local variables in the context. Of course the same effect can be achieved by exisitng language constructs. But one has to use types explicitly for that which makes the context more obvious. Another obstacle to me seems to be the quite complicated constructs of the closure return statement, especially non-local transfer. When calling a method with a closure as parameter, the closure might be preserved for later use within the instance called. This may introduce new points of failure or hard to analyze code. Additionally there may be problems with serialization.

As a last point for today, as far as I understand what I read so far, one of the most valuable uses of closures is in conjunction with collections. For that, the Java collections must be reviewed, adding new interfaces to them.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Amol Joshi

    I agree to what you say.On of the major contributor to the success of Java was its simplicity.Code after 1.4 is surely less readable because of the new features.

    — Amol

    1. Markus Kohler
      Of course I disagree here. You could say that about the templates they introduced with JDK 1.5.

      Closure are *not* difficult to use. They can be used to make a lot of things very easy to use.
      It’s most likely difficult to understand how to implement them efficiently, but that doesn’t matter for the average developer.


  2. Markus Kohler
    If you have never worked with a language with full closure support, I can recommend you to take a look at Smalltalk. Closures simply make some things much easier. Some things in Ruby on Rails for example, are so easy because closures are used. Closures are not just function pointers.

    “We” Smalltalk guys have always said that not having  closures in Java is just plain stupid.

    It seems now,they (Gosling) finally got it.
    Also they don’t talk about yet, about also supporting continuations.


    1. Richard Birenheide Post author
      Hi Markus,

      I think if I want to value closures I don’t get around with just having a look to a language. What makes a lot of my experience with Java is not that I am playing around with it but that I am literally floating in it, i.e. colleagues are working with it whose code I am using and I even use code from people I do not know. I am ought to maintain code I’ve never written. Thats the difference. There are many features in C, C++ or ABAP I find funny and refreshing when I program for myself but which can be uttermost ugly when working together with several hundred programmers. My blog is about the latter. Does it really improve maintainability? At least I consider it being a break with being strictly object oriented, something I strongly dislike with C++.

      As a result I am afraid that looking at Smalltalk does not solve my ambuigities although I might (probably) like the language (I like C and C++ as well; I grew up with it. But I wouldn’t like to use it in large teams).



Leave a Reply