The Source for Java Technology Collaboration
User: Password:



Start New Message Post a Reply

Subject:  Some good changes others bad
Date:  2007-08-16 12:05:31
From:  heathm
Response to: Some good changes others bad



Now come on, you can't argue that people that do not want closures are to stupid to understand them. So they must be to stupid to use Ruby or Groovy!?


I'm not arguing that people are too stupid to understand closures. I apologize if my comment came across as such. I am arguing that many people argue against closures without taking the time to figure out what they are and what's being proposed. I can certainly understand people not looking into the various proposals out there because a lot of proposals out there and a lot of them are poorly explained and look very complicated.


The problem is not that closures are not a good feature, but that Java gets overloaded with more and more esoteric features that are not needed but greatly extend complexity, bring very little effective gain and do not fit in a very mature language... And you can bet that no simple and elegant solution would be chosen for closures in Java (as the one from Mr Bloch). Look what they specified for Generics, just to provide type-safe containers. Closures will add another equally complex chapter to Java, just look at the proposal of Mr. Gafter.
</blockqute>

This argument that closures complicate the Java language needs to be justified. Look at the examples by Mr. Gafter in this presentation: http://www.parleys.com/display/PARLEYS/An%20update%20on%20Java%20Closures

All the examples presented here simplify the Java language not make it more complicated. There are examples that show how closures can be used to reduce boilerplate code. Boilerplate code is never a good thing. Removing boilerplate code simplifies code. Can you really argue that creating a closure is more complicated than creating an anonymous inner classes? Try to explain to a garden variety Java developer why variables outside an inner class have to be declared final and watch his eyes glaze over. Inner classes are far more esoteric than closures. I would like to see some justifications for closures complicating the Java language when I have seen example after example demonstrating how closures will actually simplify the Java language.

Granted, there are some details to closures that are complicated and arguably esoteric but the fact of the matter is that you will rarely, if ever, need to get into those details. Closures will be used primarily in place of anonymous inner-classes.


And no end is in sight; operator overloading per se is no stupid feature too as is aspect oriented programming and so on. You cannot include every smart feature from some other language because this results in a confusing mess. Java is no elegant but has been a handy and effective language. This was the reason many developers chose Java. (Ruby or Python were already available at this time). I think it is better to have several programming languages, each with some distinct smart features than to have another C++.


So because Java has been "a handy and effective language", there is no room for improvement? There are certainly a lot of language features that Java doesn't need or want but my desire for closures do not stem from the fact they're included in other languages. Nor does my desire for closures stem from them being the "idiom of the season." I want closures in Java because they simplify Java. They make it possible to do things that can't be done using inner classes. They reduce boilerplate code which reduces code complexity and reduces common mistakes (especially those made by new developers.) They make my life as a Java developer easier.


If you want closures and Java, use Groovy. Why force everyone to use closures just because it is the idiom of the season?


Who's forcing you to use closures? Is someone forcing you to use annotations? What about generics? Is your manager threatening to fire you if you don't use the new for loop syntax?



In my view closures are mainly an elegant (and currently hip) idiom for iteration but you cannot do anything with them that can't be already done.


What? A hip idiom for iteration? Is that all you see closures having to offer? There are a lot of things that closures can do that can't currently be done. For example, if you have an inner class in a for loop, can you break out of the for loop from inside the inner class? No you can't. Can this be done with closures? Yes it can.

I stand by my original statement: I have yet to hear an argument for not including closures from someone who actually understands what closures are.


Yes, they can reduce boilerplate but if examples are given, exception handling should be included! Here the devil is in the detail. Thats different to Ruby or Groovy where you need not to do exception handling.


Watch the presentation at the URL above. It includes plenty of examples with exceptions and closures. It also includes a lot of examples showing that closures are far more than "a hip idiom for iteration."

 Feed java.net RSS Feeds