This review describes the details of all the changes and additions made to the Java SE platform specification in Mustang that aren’t themselves specified by their own JSRs. Small enhancements such as the new java.awt.Desktop class, e.g., are specified in this maintenance review, whereas a big new feature like the compiler API is specified by its own JSR, 199.

The maintenance review also contains countless small corrections to the platform specification. The bulk of these are summarized in a set of API difference pages which show the changes made between Tiger and Mustang.

This is just the first Mustang maintenance review, reflecting the content of the first beta release. There’ll be another MR around the time of the second beta release, and a final MR for the release candidate. The second and third MRs are expected to be much smaller than the first.

The past is prologue

How is it that we’re doing a maintenance review for Mustang when Mustang hasn’t even been finished yet?

Good question! In fact technically this is a JCP Maintenance Review of the Tiger (J2SE 5.0) specification, JSR 176. This is just an artifact of the way that the Java Community Process works. The smaller, non-JSR changes and additions in the Tiger release, likewise, were covered in maintenance reviews of the Merlin (J2SE 1.4) specification, JSR 59.

Comments welcome!

The formal MR-1 period ends in thirty days, but you can send feedback to the e-mail address listed in the review materials at any time.

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.

The Early Draft Review version of the JSR 270 specification, which governs the content of the Java SE 6 “Mustang” release, is now available.

JSR 270 is an “Umbrella” JSR, so it doesn’t define specific features itself—instead it lists features defined in other JSRs, or in the concurrent maintenance review of the Java SE platform specification. As an improvement over past umbrella specifications, this time around we’ve augmented each feature description with non-normative links to the relevant draft Mustang javadoc as well as any associated JSRs or other material.

When reviewing this draft please keep in mind that the Umbrella JSR only covers the component JSRs and other big-ticket or highly-visible items in Mustang. Most smaller enhancements aren’t listed in the Umbrella JSR, though of course they will be covered in the maintenance review of the platform specification that’ll start around the time that the beta release of the reference implementation ships.

Mustang is still under development. The JSR 270 Expert Group has approved all of the features listed in the draft, and we expect to see all those features in the final release. It’s still possible, however, for a feature to be dropped if, for example, it turns out to be too difficult to implement. It’s also possible for new features to be added, given sufficient justification, though at this stage big changes to the overall shape of the release are pretty unlikely.

Comments on this draft are most welcome! The formal EDR period ends in sixty days, but you can send feedback to the e-mail address listed in the draft at any time.

Sneak Preview

Here’s a summary of the approved feature list sorted by area, component, and feature name. For more details please see the EDR specification.

You can check out the initial implementations of many—though not all—of these new features in the weekly snapshot builds of the reference implementation.

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.]]> 2008-01-02T17:42:16Z 2005-11-10T23:20:58Z tag:weblogs.java.net,2005:/blog/mreinhold/158.3608 2005-11-10T23:20:58Z

Even more amazingly, our QA team is happy with it!

Our hard-working QA team recently presented a summary of their results based on the near-final builds of Tiger. Overall this is looking to be the most stable and reliable JDK that we've ever shipped. Here are the highlights of their report:

• Applet compatibility     We test a set of over 400 applets, nearly all of which are external, to make sure that they run as well on Tiger as they do on any other popular VM, most especially the old and somewhat quirky VM from Microsoft. 97% of these tests pass, which is a much higher fraction than for any previous JDK release. The few failures are mostly due to applets that are relying on behavior that's outside the scope of the J2SE specification.
• Reliability     We run a set of five large server-class applications, including Sun's own application server, another well-known application server, and Tomcat, on some big iron under heavy load to see how long they stay up. As of this writing they've been up and running continuously for 28 days -- at some point we'll have to decide when to shut them off. This is a much longer uptime than we've achieved in previous releases.
• Conformance     The 1.5 JCK (Java Compatibility Kit) contains a whopping 45,194 tests (for comparison, the 1.4.2 JCK had a mere 27,309 tests). Tiger passes all of them.
• Regression tests     These are tests written by development engineers to make sure that a bug gets fixed and stays fixed. 99.7% of the tests in the regression-test suite pass. We've carefully reviewed the few failures, and in all cases we decided that the risk of fixing them at this late stage outweighs their relatively small end-user impact.
• Functional tests     These are tests written by quality engineers to test the overall functionality of the JDK. 99.7% of the tests in the functional-test suite pass. As with the failing regression tests, fixing the few remaining failures is just not worth the risk right now.

A total of 8,002 features, enhancements, and bug fixes were integrated into Tiger, so when I step back and think about it this way I'm fairly amazed that it's working so well.

Tiger is the highest-quality JDK that we've ever built. Is it perfect? No, of course not. There are no doubt still some bugs lurking, but hopefully none is too serious. If Tiger quality is important to you then please download and test the release candidate and let us know right away if something's wrong. The next couple of weeks are our last chance to fix any thermonuclear, hair-on-fire, sky-is-falling showstopper bugs.

Our main motivation for doing the snapshot releases is to ensure that the FCS release of J2SE 1.5.0 is of the highest possible quality. The end-game of a big software release, as anyone who's survived one knows, is a particularly tense time during which every change is closely scrutinized, lots of hard decisions must be made, and there's never enough testing. By posting each weekly build on the web we're hoping to increase the level of external testing and thereby improve the quality of the final result.

A second motivation for doing the snapshot releases is to gain some more experience with the "release early, release often" development style that's been so successful in the Open Source community. The Tiger Snapshot model isn't exactly "release early", since these are post-Beta 2 builds, and it's not quite as "often" (i.e., nightly) as some projects, but it's a more aggressive one than we've ever tried before. If this experiment goes well then we'll consider releasing even earlier and oftener in future releases. ]]>