Recently in java Category

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.

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?

I've been focusing on JavaScript recently, so I missed this when it first came out:
Closures for Java. I think it is interesting that the motivation for finally doing this is to facilitate APIs for concurrency.
Sun will not be using any of the existing closures proposals as a starting point, but their initial ideas are perhaps closest to the FCM (first-class methods) proposal.

There are further details here including the ominous admission by Sun that they don't feel they can get any JSRs (for closures, Project Coin, or Java 7) approved by the JCP until they resolve their dispute with Apache. In the meantime, development of closures and the Coin extensions is happening outside of the JCP in the OpenJDK.

In related news, the schedule for OpenJDK7 has slipped and a final release is now due in September 2010. Note that this is the schedule for the JDK7, not for Java 7.

I've just released Jude version 1.07. This is a relatively minor bug-fix release. Thanks to B.L. for reporting the bugs and helping to isolate them.

Interestingly, one of the bugs reported against the previous version was an ArrayIndexOutOfBoundsException at a spot where such an exception really was not possible. This had me really puzzled--I could not duplicate it. But when I discovered that inserting debugging println() calls made it go away, I realized that this was a JVM problem and not my bug. It turns out that in Java 5 (we tested u17 and u18) on Linux (at least) running with the -server option would cause this spurious exception. Running with -client (which is the default for most installations, I think) would not cause it. The crash never occurred at precisely the same spot in a run, leading me to think it was a GC bug. Unfortunately, I've got no idea how to isolate a bug like this with a simple test case so that I can report it.

I just read that closures are being added to C++ [PDF link].

A note to Sun: you know your language is falling embarrassingly behind if the C++ standards committee can move more nimbly than you can!

(For those who aren't already sick of reading about closures in Java, Neal Gafter is developing a prototype Java compiler that supports closures, and he even has a JSR proposal drafted and ready to go.)

The first article of my new column on Java 7 is now up on java.net.

In the article I discuss the jdk7 and OpenJDK projects at java.net, mention some projects that are being developed openly and might become part of Java 7, and speculate that, because of schedule constraints, Java 7 might include a lot less than we were told to expect 10 months ago.

Future installments of the column will, I hope, go into more depth with specific APIs and will actually include code examples.

Jan Lewis has written and recorded a great version of Desolation Row well suited to current events. You can hear and watch at http://www.youtube.com/watch?v=MQNBJpapIpQ.

Jan says he's a Java programmer, which allows me to make the weak case that this post is appropriate on this blog. New blog editorial policy: I'll consider linking to war protest songs written, recorded, or even just submitted by Java and JavaScript programmers and their ilk! :-)

If you're not a Bob Dylan fan, you may not be able to fully appreciate Jan's song, but it is still good. See my last post from December 2006 for the lyrics to the first verse of the original

I'm told that Sun will have a major announcement about Java on Monday November 13th.

Details will be (but are not yet) at this URL: http://www.sun.com/opensource/java

Surmise what you will from the URL path...

Remember Groovy, the JVM-based scripting language that the Java world was abuzz about? I gather that it has bogged down in the JSR process, and all the buzz seems to have faded away. I don't know if this means anything, but the following email just came in from the JCP:

To: JCP-INTEREST(at)java.sun.com
From: Liz Kiener
Subject: JSR 241 - Spec Lead Change - The Groovy Programming Language
------
The Spec Lead of JSR 241 has changed from James Strachan to
Guillaume Laforge.

I don't know James or Guillaume, and I don't even know Groovy, for that matter. But wouldn't it be nice if this change got us a standardized version of Groovy sooner?

Sun has published a list of Java 6 changes to existing APIs. I don't think that any of these changes are particularly new, but the list itself appears to be new. Seeing all the changes collected in one place was useful. Highlights for me included:

java.util.Arrays.copyOf()     // Easier than System.arraycopy
java.io.File.getUsableSpace() // Free space on filesystem?
java.awt.Desktop              // Launch web browser, etc.
java.awt.SystemTray           // Put an icon in the tray
java.awt.font.TextAttribute.KERNING_ON  // Fancy text layout

Note that this list does not include brand new APIs, like the Scripting API and Compiler API that are in Java 6. For a list of those, see JSR 270.

Build 57 of Java 6 includes a new class java.io.Console.

Javadocs are at the link above. And you can also leran more at Alan Bateman's blog .

Highlights:

• Obtain the Console object with System.console(). It returns null if there is no console.
• a readPassword() method for reading input that is not echoed on the console
• a readLine() method for reading input from the user. Much simpler than wrapping a BufferedReader around an InputStreamReader around System.in
• Also supports printf() and format() methods just like System.out does.

Matt Croydon writes at his blog you know your programming language is complicated when Java in a Nutshell has 1284 pages and weighs 3.2 pounds.

I know! And I worry about this. And with Java 6.0 in the works, it is only going to get bigger...

Unless some clever reader can think of a way to shrink it!

Comments are open...

Java 6.0 ("Mustang") includes a JavaScript interpreter and a javax.script package for interacting with it. The code below is an example of how it works...

I got email today from the JCP. JSR-270 (the umbrella JSR for Java 6) has changed its name:

The Spec Lead of the following specification

   JSR-000270 J2SE 6.0 ("Mustang") Release Contents

has updated the name of the JSR to be

   JSR-000270 Java SE 6 ("Mustang") Release Contents

The 2 is finally gone! J2SE is now "Java SE"!