Skip to main content

This Temporary Life

Posted by editor on February 26, 2008 at 7:25 AM PST

The work-in-progress version of FCM closures

Forking was one of the inevitable consequences used as an argument against open sourcing Java, yet it's proving to be an invaluable aid in prototyping features for the next version of the language. You may already know about the Kitchen Sink Language project, an experimental javac branch where new ideas can be tried out. Nothing there is meant to be perfect or even to last, which is the whole idea of experimentation. Better to prove or disprove an idea off on a JDK branch than in a shipping product, right?

Of course, the biggest topic in the Java language today is closures, and one of the rival closure proposals has gone a similar route to provide an early preview of how it might work.

Stephen Colebourne, co-author of the FCM ("First Class Methods") Closure proposal, has announced that an initial prototype is now available from the Kijaro project. "I'm happy to announce the first release of the First Class Methods (FCM) java prototype. This prototype [is for] anyone who is interested to find out what FCM really feels like." Based on JDK 7 b23 (the last JDK 7 drop before the Mercurial cutover), the prototype supports method literals, constructor literals, field literals, static method references, bound method references, constructor references, and anonymous inner methods.

Of course, this being experimental in nature, certain caveats apply:

Standard disclaimer: This software is released on a best-efforts basis. It is not Java. It has not passed the Java Compatibility Testing Kit. Having said that, in theory no existing programs should be broken. Just don't go relying on code compiled with this prototype for anything other than experimentation!

This seems like exactly the kind of good forking that was expected from the GPL release of Java. There's no confusion that the resulting code is Java™, no need to call in the lawyers. The fork is entirely experimental, meant not to last, and the results will guide development of the true JDK 7.

Whether or not FCM is your favorite closure proposal, or if you even want to see closures or anything like them in JDK 7, it's great that Stephen has committed his group's ideas to code and offered them up for all to try out.

Also in Java Today,
the Aquarium announces that OpenSSO has released Build 3 of the open-source single-sign-on implementation. Key features in this release are new SAMLv2 profiles (Attribute Query, Authentication Query & Name ID Mapping), OpenDS replication, upgrade / co-existence, timed task changes in session and LDAP, legacy DIT support from Access Manager 7.x DIT, JBoss support, Geronimo support, and lots of issues fixed.

Details about a special Java Robotics event have been posted to a Java Meetup event page, scheduled for March 3. "This meeting is for both beginners and pros and involves some hands-on "play"-time, so if you'd like to participate, you'd want to be already proficient with Java. Shawn Silverman will present an informal 2-3 hour seminar on Embedded Java and Robotics, featuring Trackbot and SunSpot."

Ed Burns let us know about a "status update on the controversial JSF 2.0 JSR", which we feature in today's Weblogs.
JSF 2.0 Update, he writes:
"here's an ultra quick update on where the JSR-314 Expert Group is with JSF 2.0 developments. Everything relating to JSF 2.0 Expert Group developments is subject to change until the Proposed Final Draft version of the spec is released."

Turning some old wisdom on its head, Scott Oaks says
Oh, go ahead -- prematurely optimize.
"Premature optimization is the root of all evil. Writing badly-performing code is even worse."

Finally, John Ferguson Smart takes
A bird's-eye survey of the world of Continuous Integration Tools in 2008.
"About a year ago, I launched a poll to learn what Continuous Integration servers people were using. The results were interesting..."

In today's Forums,
bolofsson continues to figure out how to get speed out of X11 in
Re: Swing performance on Linux.
"Thanks for your response. I think I can follow you, and I understand that working on a remote X server will slow down any graphical application. Using a VolatileImage sounds convincing enough, but unfortunately I haven't been able to make it work (fast) in practise. Following your advice, I guess my code would look like this..."

Hinkmond Wong is asking for guidance from the community in
Re: PhoneME Advanced and MIDP 3.0.
"I'm hoping we can have our official roadmap from Sun ready soon to announce on this forum to point out where we are going with phoneME and MIDP 3.0. It's not official quite yet, but it is good to hear feedback from you and anyone else who has opinions on what they'd like to see in the future with the phoneME project in the open source. Are there other people interested in seeing a MIDP 3.0 implementation developed in the open, tracked by the phoneME project? Please let me know and I will feed your input back to people inside Sun."

Scott Oaks digs deeper to explain server performance, in
Re: performance issues glassfish ejb3.0.
"But I suspect your bigger issue is with openwebload. There are a couple of reasons why it may not be the best load generator for you. First, none of its requests use keepalive, so really what you're measuring is the speed of the TCP stack on your OS; the TCP stack handles the connections. You might check various OS groups on how to adjust OS parameters for a system that accepts lots of connections, which may improve your CPU usage somewhat."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The work-in-progress version of FCM closures


FYI, The Kitchen Sink Language was pretty much DOA. It hasn't accepted any experimental ideas, and doesn't look like it will. Kijaro is now the de facto replacement for KSL, and currently has 6 branches full of goodness, with more expected :-)