mreinhold's Blog

Mustang Beta Blog Carnival!

After nearly eighteen months of effort within Sun, the Java Community Process, and the wider JDK Community, the Mustang Beta Release is now available.

In contrast to the source and binary snapshots that we’ve been shipping for over a year, the formal beta release has been through many weeks of intensive testing—and a tiny little bit of last-minute bug-fixing—in order to produce a release that’s somewhat more polished. If you’ve chosen to avoid the riskier snapshot builds then now is the perfect time to have a look at Mustang, make sure your existing code still compiles and runs, and try out the new features. Please do let us know what you think or—even better—get involved and help us make Mustang a great release for the entire community!

To help celebrate the beta release I’m hosting a “blog carnival” right here on this page. Over the next couple of days many members of the Java SE development community will post blog entries about the work they’ve been doing for the Mustang release. As entries are posted I’ll add them here for convenient reference; alternatively you can get the very latest blog entries via Planet JDK, which also provides RSS and Atom syndication feeds.

Step right up, ladies and gentlemen…

• Chet Haase channels Julie Andrews and waxes poetic about his favorite Mustang features.

• Brian Doherty reflects on the meaning of the word “beta” in this modern age of continuous integration and snapshot releases, and talks about some of the performance improvements—and pitfalls—in the release.

• Chris Hegarty explains how he fixed a high-vote bug in the HTTP keep-alive implementation.

• Sundar shows how to use DTrace on Solaris to generate a mixed-mode stack trace whenever an exception is thrown.

• Jaya Hangal talks about LDAP timeouts and connection pooling in JNDI.

• Scott Violet takes a break from big-picture application architecture to highlight some of the smaller UI features in Mustang.

• Peter von der Ahé talks about the compiler plugins—known more formally as annotation processors—that are enabled by the Tree API, JSR 269, and JSR 199.

• Sean Mullan summarizes the new security features in the release.

• Shannon Hickey introduces the new support for choosing drop actions in the Swing Drag and Drop API.

• Mandy Chung shows off six techniques for diagnosing memory-usage problems.

• Madhura Dudhgaonkar explains why Mustang Beta is based on the relatively ancient build 59 even though the latest snapshot release is build 71.

• David Herron posts a helpful reminder of the Mustang Regressions Challenge, in which you can win a slick new Opteron-based Ultra 20 workstation if you find a really egregious regression. (No purchase necessary, void where prohibited by law, etc.)

• Éamonn McManus summarizes the new JMX features.

• Chris Campbell argues with himself over whether or not the beta build is too passé, and also takes stock of the work that he and his team have been doing.

• Preveen Mohan talks about some of the new AWT features in Mustang from the standpoint of a QA engineer.

• Naoto Sato describes the new Locale Sensitive Services SPI.

• Danny Coward muses on how the new Compiler API is going to keep javac up and running 24/7/365.

• Penni Henry, the new Mustang Program Manager, reflects on the quality of the release from the perspective of someone relatively new to the team.

• Gauri Sharma discusses the ongoing work on the Mustang JCK (Java Compatibility Kit).

• Jon Masamitsu wonders whether those who want a truly “pauseless” garbage collector would be willing to pay for it in the currency of time and space.

• Andreas Sterbenz shows how to plug NSS into the Java PKCS#11 crypto provider in order to improve performance on Linux and Windows.

• Finally, in my other blog you can find a description of the new class-path wildcard feature.

That’s it for now!

Questions and answers

To answer a few of the questions that’ve been asked in the comments below:

• The beta release is based on weekly build 59 from way back in November 2005. Madhura talks a bit more about why it’s so “old.”

• Every bug fixed in a later snapshot build will stay fixed for the final release unless a problem with the fix is found in the interim and no alternative solution can be devised.

• The evaluation license is a bit, well… baroque. We’re talking to our legal team to see if the part about having to notify Sun can be removed.

planetjdk.org now publishes syndication feeds

By popular demand Planet JDK now publishes both an RSS feed and an Atom feed.

The Atom feed is in the version 0.3 format (sorry Tim); I'll set up an Atom 1.0 feed just as soon as ROME supports that version, which hopefully will be fairly soon.

As I mentioned previously, Planet JDK is open to anyone who's contributed code into the Java SE Development Kit. If you've contributed a Mustang fix and your blog isn't listed on planetjdk.org then drop me a note and I'll add it.

Mustang Component JSRs

The JSR 270 Expert Group recently decided upon the set of component JSRs that will appear in Mustang, a.k.a. Java SE 6. Here they are, grouped together by area:

There are a few differences between this set and the set originally proposed in JSR 270:

• JSR 173, the Streaming API for XML, was added; it's a prerequisite for both JAXB 2.0 and JAX-WS 2.0.
• JSRs 181 (WS Metadata), and 250 (Common Annotations) were added; these are prerequisites for JAX-WS 2.0.
• There is no JSR for "JAXP.next"; instead a minor maintenance revision of JAXP will be proposed for Mustang.
• JSR 268, the Java Smart Card I/O API, was dropped. Platform implementors are of course free to deliver an implementation of this JSR alongside their Java SE 6 implementations, which is what Sun intends to do, but JSR 268 won't be a required part of the platform.

Mustang's final release is slated for the third quarter of 2006. A lot could change between now and then, but unless something truly surprising happens then these are the JSRs that will appear in Mustang.

Mustang Snapshots: Another experiment in openness

Way back when I was an undergrad I had a professor who was a stickler for experimental method. She was also, however, always anxious to see what you had learned. As soon as she understood your experimental setup -- which was usually before the end of your explanation of it -- she'd insistently ask, "What were your results?" Between her enthusiasm for the question and her eastern-European native tongue the last word would always come out as "RHEE-zults". That question, and her unique pronunciation, have stuck in my head ever since...

Last June we did a first "experiment in openness" with the Tiger Snapshots. We posted each weekly Tiger build, in binary form, from the Beta 2 release right up to the Release Candidate. The results were positive: About ten thousand brave souls downloaded the builds and filed several dozen bugs, and the most critical handful of those bugs was fixed in time for the RC build.

Inspired by the success of the Tiger snapshots, today we posted the first of the Mustang Snapshots. We've made some significant changes this time around:

• We've started earlier. You can get build twelve today. Yes, that's twelve as in 12. There aren't a whole lot of changes in this build, mainly just bug fixes and a few small enhancements here and there, but you'll see more change going forward as new features are integrated.

  As usual, snapshot builds are not for the timid. They receive only limited testing -- just a few hours' worth to make sure that they're warm and breathing. If you want stability then you'd best wait for the Mustang beta release, but if you enjoy living on the bleeding edge then these builds are for you.

• We're shipping source bundles. For the first time ever we're shipping source bundles for a J2SE release while it's under active development (gulp). This should make it easier for interested developers to contribute to the release as it evolves. In past releases the only ways to do that were to be lucky and know someone at Sun, or be lucky and have your suggestion survive the labyrinthine gauntlet of the bug-submission process.

  Posting source bundles will also make it easier for us to be embarrassed by our mistakes, but we're quite happy to be arbitrarily embarrassed in exchange for higher quality.

• We're using java.net. One of the big goals here is to engage better with the developer community, and java.net provides excellent infrastructure for that. The bundles are being hosted in the overall j2se project, which will shortly acquire the other usual project accoutrements such as mailing lists and forums. We're also working on a streamlined process for patch submission so that you can send code directly to real live JDK engineers rather than paste it into a bug report, cross your fingers, and hope for the best.

• We're using a new license. The source bundles are covered by the Java Research License. The JRL is, to my non-lawyerly brain, a big improvement over the old SCSL license -- for one thing, I can understand it! The JRL also gives developers and researchers more flexibility than SCSL did, though it's still not an actual open source license in OSI terms (sorry).

Taken together these changes obviously entail a much bigger, and longer, experiment than the Tiger Snapshots. We certainly don't want to wait until the end to learn from the experience and make adjustments. If you have ideas on how we could do any of this better, please let us know!