Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Dionysios G. Synodinos on Nov 19, 2009
During his Devoxx talk, Mark Reinhold has announced that JDK 7 will have Closures. With the inclusion of this much debated feature, JDK 7 schedule will be extended until around September 2010.
Joseph D. Darcy, lead engineer of Project Coin, which aims to make small language changes for Java 7, has confirmed that the next version of the language will include some kind of “lightweight” Closures:
… JDK 7 will have closures, a to-be-developed from of closures smaller than BGGA, and that the JDK 7 schedule will also be extended until around September 2010.
Alex Miller who attended the talk points out that Sun has been negative about Closures although the community had produced 3 different proposals in the past:
I can’t say what to make of that really. For years Sun has been saying that there is no consensus on closures and delayed the formation of a JSR or expert group on the subject despite having three proposals, all with prototypes.
After the announcement at Devoxx, Neal Gafter who was a co-author for one of the three Closures proposals (BGGA, named after the initials of Bracha, Gafter, Gosling, and von der Ahé), has released a “simplified proposal”:
Changes in this revision
- The control invocation syntax has been moved to a separate specification.
- The term closure literal has been replaced by lambda expression.
- We overhauled the syntax for lambda expressions, borrowing loosely from Clang. There are now two forms of lambda expression: an expression lambda has a controlled expression, while a statement lambda has a controlled statement.
- The term closure object has been replaced by function object.
- The term closure conversion has been replaced by lambda conversion, with a separate block conversion for the control invocation syntax.
- Added new semantics for the return statement: it can now be used to return from a statement lambda.
- Renamed java.lang.Unreachable to java.lang.Nothing ala Scala.
- Removed support for the type name null. The previous version used null as a placeholder for an exception type when none can be thrown. The type
Nothingnow serves that purpose.- Overhauled restricted. The concepts of restricted and unrestricted function types and closures have been removed. Now, all lambda expressions are restricted. The equivalent of the previous specification's unrestricted closure may be passed to a method by using the control invocation syntax.
- Added support for method references: We added support for treating a reference to a method as a function using a newly introduced token
#. The syntax is borrowed from cross-references in javadoc and the FCM proposal.
This sudden change in plans for JDK 7 has made people like Fabrizio Giudici skeptic about the decision process:
I don't want to discuss whether it's a good or a bad thing (
you know I think it's badI suspend any judgment as I understand that the proposal is neither BGGA nor CICE, but something new). I'm only appalled that after a few weeks that the final word of Java 7 had been said with Project Coin (the famous final five or so), somebody changed his mind all of a sudden. What kind of decisional process is this?
Ah, I got it - it's tossing a coin, now I get where the project name came from. I fear Java 7 could be the most chaotical Java release ever - a very good idea if you want to kill it prematurely (as it there weren't already many other sources of entropy, such as the Oracle deal or the Jigsaw / OSGi debate).
Similarly Geertjan Wielenga thinks that the inclusion of Closures was a very unexpected development:
Great news and maybe best if no one asks too many questions about how that process ended up throwing up this solution! First, we have a whole bunch of proposals, all of which get lukewarm reception. Then, suddenly, like a bolt from the blue, we have "simple closures". (I wonder if any of the existing proposals are called "complex closures". Isn't simplicity the whole purpose of closures in the first place?) OK, the closures will be simple in the sense that there will be no non-local return, no control statements, and no access to non-final variables. Still, how was that decision made?
Cay Horstmann, provides several use cases for this new BGGA proposal, which is very similar to the FCM proposal:
We don't really know what exactly Sun intends to do. I simply analyzed the BGGA 0.6a proposal, which is presumably what BGGA is today. There is no denying that it looks a lot like FCM. No non-local returns. # for lambda. Since you need to annotate a mutated variable with @Shared when you capture it, perhaps people would think twice before writing
foreach(@Shared String v : values) funcs.add( #() => v);
As Alex Miller mentions, the extension of the JDK schedule might make it possible for other features to make it into the release, like the the ParallelArray library which provides a functional style API for mapping, filtering, reducing over an array of Java objects:
I talked to Bob Lee a bit at QCon and he thought it was possible that the extended timeline for JDK 7 may allow the ParallelArray work to come back in and make use of the new closure support.
You can find more information about Closures and JDK 7 right here on InfoQ!
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
The 5 Mandates of Software Development Teams - Presto Manifesto
Innovation in Your Data Centre
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
I can personally attest that I did not actually attend the talk at Devoxx, as I am actually at QCon right now. I'm into distributed computing and all that but I am not myself yet distributed. :)
Alex
... I wish they also added the final Exception - throws declaration improvement
I like Sun. Really I do. I might be in favour of adding closures to Java if they can find a formula that is less baroque then the original BGGA specification (and the new draft has already got rid of the distinction between "restricted" and "unrestricted" closures which is a good start). But what the hell is going on here?
As a decision making process for one of the most important bits of technology around today this is an absolute disgrace. How is Sun deciding what does and does not go into Java 7? More to the point why is Sun deciding what does and doesn't go in to Java 7. The whole process is ludicrously opaque. Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé were apparently all in favour of adding closures to Java 7 but there wasn't enough "community support" (whatever that means) to do it so Sun dropped the idea. So what has happened since? Did the wind change direction? Was fiery Mars suddenly in the more orderly sign of Capricorn? Has Josh Bloch suddenly said "actually, you know what, I think this a good idea" and everyone sighs a sigh of relief and says "OK lets get on with it".
The insane thing about all this is that Sun has a process, the JCP, which actually works pretty well. I know people like to bash the JCP, but, to misquote Winston Churchill, it’s the worst form of governance in the world accept for all those others that have been tried. For one thing needing to produce a spec, a reference implementation, and a test suite prevents the sorts of abuse that other standards bodies suffer(1), and yet when you know what you want to standardise things can get happen very quickly (as JSR-330 recently demonstrated). It has produced some amazingly good things (EE 6 for a start). But what? It isn’t good enough for Java 7 anymore since Java was open sourced? We can't use it because those nasty people at Apache might vote against the JSR and then where would be? We can't use it because Java is mine, mine do you hear and noone else can play with it (evil gloating laugh). We can't use it because we wanted to play with our toy one last time before Oracle buys us/we go under? What?
---------
1: Microsoft Open Office XML, a "standard" which noone, including Microsoft has actually implemented, I'm thinking of you here
I don't have an opinion on the decision-making process (plenty of other ppl seem to have that covered) but I am glad to see closures get included sooner rather than later.
Hopefully the extended release date will also allow them to apply closures to the various JDK APIs where they make sense (e.g. collection traversal/mapping/filtering, resource management, etc.) Inclusion of fork-join in the JDK7 should be a given too since it will have the necessary closure support.
I would like to add a +1 to every word of this comment.
Being the developer of the lambdaj project I am sure I am a bit biased, but I believe this situation is becoming truly ridiculous.
This proposal provides more or less the same set of features offered by lambdaj (actually lambdaj has also curry that seems missing in this spec). The only advantage i can see here is a nicer syntax.
But I took 3 days to develop closures in lambdaj, while (if everything will go as claimed and I am not sure of that) it will need about 3 years to have the same stuff in jdk7. Indeed I remember I am participating to discussion about closures since late 2007 and now they are telling us that we will have them in late 2010.
The elephant is going to give birth the mice.
Two comments:
1. In the presentation, IIRC he specifically said that the Parallel Arrays stuff would be omitted (because it adds a few billion classes to the JDK).
2. He said in the presentation that the closure implementation is going into JDK 7 (I assume "Open JDK", which is an open source project); he did not know whether or not it would make it into Java 7 (which is controlled by the JCP, and thus not available for direct control by Sun).
Peace,
Cameron Purdy | Oracle Coherence
coherence.oracle.com/
As I have written in Facing the wall of closure Java (difficult) adoption, the problem is: adopting closures is one step, adopting type inference is another step, and adopting both, as the same time, while it would alleviate the closure burden, could be too much enough for some developers.
Or, to say things differently, making one step (closure adoption) does not let developers happy (due to different closure opinions) and making two steps in one move (closure+type inference adoption) would alleviate the closure burden, would be a good closure/type match , but it is too much enough for some developers.
So, the problem remains.
I have no preference for a closure proposition. And that's a pb when no proposition has the lead.
But if something coul/would be introduced into JDK 7 for making a step towards closure, I prefer to enable automatic method autoboxing into interface(implementation) as stated in Next JDK wishlist-3: a first step towards closure into Java.
Dominique
www.jroller.com/dmdevito
In the spring, lots of people were angry because the closures went out of the scope for java 7. Now they are angry because it's back in. I guess some people are hard to please.
I guess some people just would like to see a clear direction in the development of the language's features instead of this unbearable mess.
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.
10 comments
Watch Thread Reply