Summary
At the Devoxx conference in Antwerp, Belgium, Sun's Mark Reinhold announced that closures would be added to Java in JDK 7. In this interview, Stephen Colebourne, coauthor of the FCM closures proposal, gives his perspective on this surprise announcement.
Advertisement
One year ago, Mark Reinhold, Principal Engineer at Sun Microsystems,
announced At the Devoxx conference in Antwerp, Belgium that the next
major release of Java, JDK 7, would not include closures. At the same
conference this year, however, Reinhold announced in a surprise turn
around the Java would be getting closures after all in JDK 7. I sat
down with Stephen Colebourne, project lead of joda.org and coauthor of
the FCM closures proposal, to discuss his perspective on the reason
for this change of plans.
Bill Venners: What do you think is the reason Sun decided to include
closures in JDK 7 after announcing one year ago that they would not?
Stephen Colebourne: One year ago Sun’s judgement was that there was
not enough time to get closures into JDK 7, there were too many
competing proposals, and not enough experience to decide which one to
use. One factor is that because JDK 7 has been delayed until the end
of next year, that allowed more time. In addition, their experience
with Neal Gafter’s BGGA proposal implementation meant that they could decide
what bits they would and wouldn’t want.
The BGGA proposal was the most complete implementation of closures
from a theoretical perspective. I think Mark Reinhold evaluated BGGA
and determined that non-local return and control invocation
statements, which BGGA originally had, are not appropriate for Java.
In the latest version of the BGGA proposal, v0.6a, Neal Gafter has
taken out non-local return and control invocation statements. Once you
take that out of BGGA, what you end up with is something that looks
very similar to v0.5 of the FCM proposal. I’ve suggested that we
rename the 0.6a proposal as CFJ (Closures For Java).
Bill Venners: What other factors do you think influenced the decision?
Stephen Colebourne: I think a key factor that changed people’s minds
is the fork-join framework. Doug Lea completed the work on fork-join.
Sun looked at including into JDK 7, but one part, the parallel array
API, which includes predicates and transformers that operate in a
functional style over arrays, was just too complicated. In order to
make it work, it needed 80 interfaces, and that only covered four
primitive types. To cover all the primitive types you’d need 80 more
interfaces. Also, it was extremely unfriendly to the coder. You had to
use an inner class and get the generics of the inner class right. You
had to pick the right interface of the 80 choices. Closures will make
that API much simpler and easier to use.
I humble Java developer has to ask himself what is the decision process for Java?
As I sat in the Devoxx fork-join presentation last year (the inner class API with 100 generated types) I could tell that this is just a terrible API (like all functional programming in Java). It is unnecessarily hard to use compared to a closure based implementation (that is possible in practically every other language). Did the Sun management need one year to get that?
It would be nice if OpenJDK were a real open source project. (Having writing zero lines for OpenJDK I should not complain.) That the Sun/JCP smoke screen would be removed and decisions are done on technical merit in less than three years.
The fork-join parallel array api was always a driving example behind closures. What was previously lacking was the time to arrive at an acceptable form of closure.
More interestingly, will this drive a renewed interest in closures from developers who had previously written them off as not being relevant?
After that, once people are interested. It'll still be a year-long wait before JDK7 comes out, and even longer before it gets installed on back end deployment environments.
I'll be very closely watching what impact this has on the adoption rate of Scala, which offers closures right now on the 1.5 JVM and only requires an extra jar on the classpath to work. Plus you get type inference and all the other goodies.
> It would be nice if OpenJDK were a real open source > project.
Having seen well respected open source projects go through phases where the release manager would close issues as "we [I?] don't feel like this" and reject patches for the same, I guess I don't know what a "real open source project" is or how other real ones I know of are necessarily better than OpenJDK.
I'm not saying OpenJDK is perfect, but lack of perfection does not make it unreal.
> > It would be nice if OpenJDK were a real open source > > project. > > Having seen well respected open source projects go through > phases where the release manager would close issues as "we > [I?] don't feel like this" and reject patches for the > same, I guess I don't know what a "real open source > project" is or how other real ones I know of are > necessarily better than OpenJDK.
The key is in the name: "Open Source" does not imply "Open Management" or any other type of project management.
It would be great if this project could be completed within the next year or so but I honestly see it taking a lot longer. It all seems to be a bit of a mess.
Previous Topic
