May 2010 Archives

Last Wednesday, I blogged about the fact that closures discussion on the Project Lambda mailing list had petered out.

It appears I spoke too soon: on Friday an Oracle engineer posted a substantive strawman proposal, and followed it up with another significant document on Monday. These have generated much discussion on the Project Lambda mailing lists, and things seem to be moving again.

Yesterday, Neal Gafter "read the tea leaves" and surmised that Oracle has at least three engineers working on closures.

Its nice to know that the project isn't dead. Of course we still don't know whether the Java 7 schedule will slip to accommodate closures or if closures will be postponed for a later release. So the "not likely" assessment from my original post still stands.

I've just realized that there is one annoying JavaScript special-case that web developers no longer need to know about, and I don't need to document anymore.

As you know, JavaScript event handlers return false to cancel the browser's default action for the event. Except, that is, for the onmouseover event handler. Because of a bug in Netscape 2.0 (I think) we've always had to return true for that one. Documenting this special case has become a habit for me.

How nice, therefore, to realize that this is now irrelevant. The only default action associated with a mouseover event is to display the destination URL of a link. But to prevent phishing attacks, browsers no longer allow us to cancel this default action (and no longer allow any kind of status line scripting). Since the action can't be cancelled, the return value of onmouseover no longer matters. Hooray!

So I can now just document "return false to cancel". (Of course I still have to document e.preventDefault() for event handlers registered with addEventListener() and e.returnValue=false for event handlers registered with attachEvent(), but this is a step in the right direction.)

Five months ago, I posted Closures in Java 7 After All to celebrate the announcement that JDK7 would include closures.

The schedule seemed optimistic at the time, given that Mark Reinhold decided to start with a blank slate rather than adopting one of the existing closure proposals. And sure enough, it was wildly optimistic. The schedule says that JDK 7 will be "feature complete" on June 3rd. But the closures specification being developed by Project Lambda is at version 0.15

Activity on the Project Lambda mailing list has petered out as engineers from Sun/Oracle have become non-responsive. [Update: this has now changed. See my more recent post.] Neal Gafter, one of the hardest-working advocates for closures in Java, has politely and repeatedly asked for clarification of the schedule and of Oracle's commitment to closures.

The only answer he's gotten is from Alex Buckley:

Schedule information for Lambda will be shared when available.

Resourcing decisions are out of scope for this list, but I am sure that any resources assigned to Lambda will be directly or indirectly visible on this list.

It seems that Alex is not permitted to speak openly about this. But given that no activity is directly or indirectly visible through the mailing list, we can infer that there is basically no one at Oracle working on closures. And it makes me wonder: is there anyone one at Oracle with the time and the authority to alter either the release schedule or the feature list for JDK 7?