Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Geoffrey Wiseman on Aug 29, 2007
Neal Gafter recently gave a presentation at JavaOne and Jazoon '07 entitled Closures for Java: ... and other thoughts on language evolution (presentation, mp3 audio, simultaneous presentation/audio).
The presentation is a gentle, but relatively thorough introduction to closures, the goals, the problem with existing solutions, all presented in an accessible, conversational style. If you've avoided reading some of the deeply technical proposals in the past, this is a good way to get an introduction and overview to the closures proposal.
He opens the presentation with this quotation from Mark Jason Dominus from The Perl Review:
In another thirty years people will laugh at anyone who tries to invent a language without closures, just as they’ll laugh now at anyone who tries to invent a language without recursion.
Neal Gafter described the goals of closures as enabling developers to accomplish the same kinds of things that they currently do with anonymous inner classes, but with less pain; integrate with existing apis, enable control APIs, functional and aggregate operations, and to be simple, but powerful.
By enabling control APIs, Gafter hopes to reduce boilerplate code, where documentation describes how to use an API with marked sections where you might add your own code, and that developers often cut-and-paste, simply because Java does not have a clear and concise way of expressing this API form.
Neal Gafter walked through how one might implement the Java SE 5 for-each loop using anonymous inner classes, pointing out the flaws in the approach along the way:
All of these examples show places where you know how to solve the problem you're trying to solve. You already have the solution in mind; it's really clear. The difficulty becomes expressing it in the Java programming language and there you have to fight with the language and fight with the compiler to let you do what you know how to do.
He then describes the syntax and semantics of the Closures proposal, and uses these in examples, from control apis with locks, through aggregate operations to Swing event listeners. He also described the new APIs that could result from language-support for Closures.
The presentation was well-received by attendees, who tended to believe that Closures for Java are important or inevitable, but others remain unconvinced. Fabrizio Gianneschi wanted to see this presentation "because I'm against closures, I missed his previous talks, I'm following his thoughts on the Java Champion's mailing lists and I would like to get convinced that closures are useful".
For more information, visit the Closures for the Java programming language website, or continue reading about closures at InfoQ.
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
The 5 Mandates of Software Development Teams - Presto Manifesto
I am still kind of skeptical about closures. From what I have seen so far, it does not look like an brand new concept (unlike generics or annotation in Java 5).
Instead I would qualify them as syntactic sugar for anonymous Java classes, much like 'for each' loop which removed indexes from Java 'for' loops. However, while the advantage of 'for each' was always evident to me due to its simplicity, I am not sure the same applies here.
Beast,
Dmitriy
GridGain - Grid Computing Made Simple
Sugar or not, I would take it in a heartbeat any day. To be able to pass around a piece of code that has a well-defined way to "execute" it is gold.
Think about set operations on collections, i.e. Groovy's collect method. Something that is incredibly common, but we just tend to avoid b/c it's not convenient to write in Java.
But think about doing that stuff using anonymous classes all the time. You'd want to shoot yourself.
I am still kind of skeptical about closures. From what I have seen so far, it does not look like an brand new concept (unlike generics or annotation in Java 5).
Huh. Nothing new? How can you say that? Look at the slides and the time("foo") { } example .. nothing new? You must be joking. This closure proposal lets you not just define anonymous method expressions, it lets you easily define new language constructs. Something that is very powerful and very much needed in Java imo.Instead I would qualify them as syntactic sugar for anonymous Java classes,
This is a pretty lame thing to say. With that sort of reasoning you might as well reject all new java language proposals because each of them is syntactic sugar for things you could already do with plain java code. That is completely besides the point here.
Closures will make the language more powerful and will allow you to do powerful things in an easy way. Wouldn't it be great to get rid of the TransactionTemplate stuff in Spring and be able to simply say: withinTransaction(tx) { updateDb(); } instead of ugly many line solution that we have now?much like 'for each' loop which removed indexes from Java 'for' loops.
I don't think you understand how foreach works. It has nothing to do with removing indexes. It has everything to do with adding a new concept with a specific contract (Iterable) to the language. Indexes are not part of that contract.
S.
This is an excellent presentation. Most of the closure nay-sayers I know personally have changed their tune about closures after watching this presentation.
To be frank, suggesting that closures are just syntactic sugar is ignorant of what closures have to offer. Closures add functionality and flexibility to the language that can't be done with inner classes. Granted, a lot of what closures have to offer is syntactic sugar but it's syntactic sugar that greatly increases code readability and reduces the need for boilerplate code. IMO, this is a must for the Java language.
Please, watch the presentation. I promise it's worth your time.
Instead I would qualify them as syntactic sugar for anonymous Java classes,
This is a pretty lame thing to say. With that sort of reasoning you might as well reject all new java language proposals because each of them is syntactic sugar for things you could already do with plain java code. That is completely besides the point here.
Disagree. Many new ideas that came in Java 5 were true new features, like annotations and generics - they simply were not possible in Java 4.
Closures, on the other hand, is an enhancement, not a brand new feature. Again, I have nothing against enhancements, but the way they are being introduced, in my opinion, defeats regular Java semantics.
For example, how do you do exception handling with closures? I think the current proposal forces you to throw runtime exceptions. What if I want to have a checked exception - am I out of luck?
Best,
Dmitriy
GridGain - Grid Computing Made Simple
I don't understand why Dmitriy is skeptical, on the grounds that closures are a trivial feature. Surely the more trivial they are the less disruption they can cause. In fact, Neal has gone to a lot of trouble to make sure that they fit well in the existing language, so if you think they seem trivial, that's to Neal's credit.
As to them being syntax sugar - you can call everything syntax sugar, above what is needed to be Turing-complete. As it happens, Java's syntax is in need of some sugar, especially when you want to write functional code.
Annotations aren't so much of a new feature, people were already doing them in javadocs using xdoclet, etc. Java 5 annotations are certainly an improvement on that. Generics are the ultimate syntax sugar, right, because of erasure?
You're wrong, Dmitriy, about semantics - as far as possible the semantics will be preserved. The only contentious issue I know of is last-line-no-semicolon for return values from closures (which I disagree with, though I know the reasoning). All your keywords are belong to you. Inside a closure, return means the same as outside it, as does this, continue, break and throw. Yes, you're wrong about throwing exceptions - the current proposal does not force you to throw runtime exceptions.
For example, how do you do exception handling with closures? I think the current proposal forces you to throw runtime exceptions. What if I want to have a checked exception - am I out of luck?
Ooops, I was wrong here :-) I missed the support for checked exceptions. It was not apparent from presentation, had to look into JSR specification for that. However once you start putting exception declarations into your boiler-plate code, it does make it less readable. But I can see the point of JSR, cases with multiple exceptions thrown out of the same block are rather rare.
As far as syntax sugar, I guess you can stretch my statement and say that everything can be called a syntax sugar. I just wanted to point out, that unlike Annotations or Generics, there is currently support in Java language via anonymous classes for practically everything closures provide. However, I do agree that closures make it much simpler in many cases, but they won't be as easy to grasp for developers as Java5 'for each' syntax though.
Best,
Dmitriy
GridGain - Grid Computing Made Simple
As far as syntax sugar, I guess you can stretch my statement and say that everything can be called a syntax sugar. I just wanted to point out, that unlike Annotations or Generics, there is currently support in Java language via anonymous classes for practically everything closures provide. However, I do agree that closures make it much simpler in many cases, but they won't be as easy to grasp for developers as Java5 'for each' syntax though.
You are wrong here, full closure support is not trivial, in fact is very difficult to implement. That's why Java doesn't allow to reference non-final variables from anonymous inner classes. To implement full closure support the VM has to be very intelligent on the handling of activation records (take a look at Closures in VisualWorks).
In Smalltalk for example closures are used to implement if/else using objects and messages:| result |
(a > 10) ifTrue: [ result := a ] ifFalse: [ result := b ].
In this code fragment result is modified inside a closure (this is impossible to do with Java anonymous inner classes). Note that #ifTrue:ifFalse: is not a language keyword, just a method declared in the Boolean class. In St [] is used for closures, and booleanObject ifTrue: block1 ifFalse: block2
is like booleanObject.ifTrueIfFalse(block1, block2)
in Java.
I had worked with Smalltalk during 3 years, and the top of my list of missing features in Java are: the hability to evaluate code everywhere, no static type checking and closures.
I think closures bring the same kind of simplicity that the for-each syntax does. Instead of having to construct an inner class with an overridden method, it'd be much better to just pass around a closure.
Disagree. Many new ideas that came in Java 5 were true new features, like annotations and generics - they simply were not possible in Java 4.
Generics are just syntatic sugar in Java as well. At runtime there is no way to tell the difference between a Box<Bar> and a Box<Foo>, both are compiled as Box<Object>.
</object></foo></bar>
This is an excellent presentation. Most of the closure nay-sayers I know personally have changed their tune about closures after watching this presentation.
...
Please, watch the presentation. I promise it's worth your time.
Agreed; I was in favor of closures anyway, having struggled with control-api issues in most projects, but I hadn't really sat down to enumerate the reasons why anonymous inner classes weren't just slightly uglier syntax. Going through the examples one by one really made an impact on me.
However once you start putting exception declarations into your boiler-plate code, it does make it less readable.
What does that have to do with closures?As far as syntax sugar, I guess you can stretch my statement and say that everything can be called a syntax sugar.
Yes, my aim there was to make it clear that dismissing something because it's syntax sugar is fallacy.I just wanted to point out, that unlike Annotations or Generics, there is currently support in Java language via anonymous classes for practically everything closures provide.
Of course there is. C programmers can emulate closures too. Neal points out pretty good reasons why you want actual closures instead of emulations thereof.However, I do agree that closures make it much simpler in many cases, but they won't be as easy to grasp for developers as Java5 'for each' syntax though.
So they're trivial and too hard at the same time? It will be worthwhile for developers to learn how to use closures, for programming in general, and for Java.
Diego Fernandez,
To allow non-final variables (other than fields) from the enclosing scope, one needs to place the variable in the closure object and have the enclosing scope read and write to that. I don't think it's incredibly hard - apparently it was disallowed in the first place for (false) performance reasons.
I had worked with Smalltalk during 3 years, and the top of my list of missing features in Java are: the hability to evaluate code everywhere, no static type checking and closures.
I think Groovy is what you're looking for.
I read through the presentation and was not convinced that closure are an improvement to
Java.
Looking at page 4 and 5:
Where is the closure defined at? Somewhere else in the class? Do I have to jump to some
other place in the code to read the closure? For me, the example was easier to read and
understand before the closure was applied because it was all in one place.
Looking at page 6:
We don't need closures to simplify the example to:
for (Map.Entry<String,Thing> e : myMap.entrySet()) {
doSomething(e.getKey(), e.getValue());
}
Looking at page 7:
What about listeners with more than one method like MouseListener?
Anonymous classes have at least one advantage over closures because they can be defined
where they are needed in the code. My impression is that closures require an additional
definition (of the closure) somewhere else in the code--which means they should be compared
with the other three kinds of nested classes (static nested, inner, and local. see
java.sun.com/docs/books/tutorial/java/javaOO/su...) Unlike closures,
anonymous classes are not intended for reuse.
Do closures provide any benefit over the other kinds of nested classes?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
14 comments
Watch Thread Reply