This review describes the details of all the changes and additions made to the Java SE platform speciﬁcation in Mustang that aren’t themselves speciﬁed by their own JSRs. Small enhancements such as the new java.awt.Desktopclass, e.g., are speciﬁed in this maintenance review, whereas a big new feature like the compiler API is speciﬁed by its own JSR, 199.
The maintenance review also contains countless small corrections to the platform speciﬁcation. 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 ﬁrst Mustang maintenance review, reﬂecting the content of the ﬁrst beta release. There’ll be another MR around the time of the second beta release, and a ﬁnal MR for the release candidate. The second and third MRs are expected to be much smaller than the ﬁrst.
The past is prologue
How is it that we’re doing a maintenance review for Mustang when Mustang hasn’t even been ﬁnished yet?
Good question! In fact technically this is a JCP Maintenance Review of the Tiger (J2SE 5.0) speciﬁcation, 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) speciﬁcation, JSR 59.
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.
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.
The Early Draft Review version of the JSR 270specification, which governs the content of the Java SE 6 ȁc;Mustangȁd; release, is now available.
JSR 270 is an ȁc;Umbrellaȁd; 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.
Here’s a summary of the approved feature list sorted by area, component, and feature name. For more details please see the EDR specification.
Many members of the JDK Community are active bloggers, but there's no one place where you can go to find their blogs. Quite a few can be found on java.net, but lots of Sun employees have blogs elsewhere—most often on blogs.sun.com—and of course non-Sun employees have blogs all over the web.
To help address this problem I've hacked up a simple aggregator and put it up on the web at planetjdk.org. I didn't have to write much new code for this since the ROME project already does the heavy lifting of parsing syndication feeds in all of their splendiferous complexity. It's still a little rough around the edges—it doesn't publish aggregated feeds itself yet, for example, but that will come soon. It's running, naturally, on the very latest Mustang build.
I've populated planetjdk.orgwith feeds for all of Sun's Java SE bloggers. I've also added feeds for the blogs of anyone who's contributed a fix to Mustang—at least insofar as I could find them via Google. 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.
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.
The expert group already has some initial members; we'll be accepting additional applications through Monday, 14 March. We won't be able to accept every application, of course, since we'll need to strike a balance between having broad representation from the community and having a manageable group that can make decisions in real time. If you'd like to help guide the future direction of the platform, please consider applying to join.
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!
Whew! I can just about hear the collective sigh of relief from everyone, both inside and outside of Sun, who contributed to this amazing product. We hope you enjoy working with it. As I've said before, I think Tiger is the highest-quality JDK that we've ever built -- and I've been helping to build these things since JDK 1.1.
This seems an appropriate time to look forward, and in particular at some changes that we're making to the J2SE release model.
The current model has three kinds of releases:
Feature releases are the big ones (1.3, 1.4, 1.5 5.0), with tons of bug fixes and lots of new features. These have generally been about 24-36 months apart.
Maintenance releases, the so-called "dot-dot" releases (1.4.1, 1.4.2, etc.), have lots of bug fixes but no new API features. Lately these have been about 8-10 months apart.
Update releases, the so-called "underscore" releases (1.4.2_01, 1.5.0_01 5.0 update 1), which contain a very small number of bug fixes (typically around 100) carefully chosen to meet urgent customer needs. Sun has shipped these about every 3-4 months.
Going forward we're going to simplify this model and increase the rate at which we ship releases. In particular:
Feature releases will ship every 18-24 months. This will allow the platform to evolve more rapidly so as to better meet the needs of the developer community and compete with .NET.
There won't be any more maintenance releases. Starting with Tiger (5.0) there won't be any more releases the size of 1.4.1 and 1.4.2, i.e., with 1500-2000 bug fixes. There still might be a release called "5.1", but it will just be a special update release.
Update releases will ship every 2-3 months. This will make it possible for critical bug fixes to be delivered to customers in a more timely manner.
Changing the release model is not something we've done lightly; this is the result of several months of investigation and many conversations with partners and developers in the community. A couple additional expected benefits of these changes are:
Releases will more likely ship on time. Within the J2SE engineering organization we've long wrestled with the difficult choice of making the current maintenance release as perfect as possible versus working on great new features for the next big feature release. This conflict has been the proximate cause of many schedule slips over the years. The new release model finally resolves this fundamental tension: J2SE engineers will, by default, always be working on the next feature release. There will be times when they're asked to fix a critical bug in an update release, and even rarer times when some nontrivial work (e.g., to improve performance) will be done in an update release, but these will be the exceptions rather than the rule.
Release adoption will improve. The existing medium-sized maintenance releases have long been a big adoption barrier. Due to the level of change in these releases many users have only been confident enough to adopt them after requalifying all of their applications -- in other words, by treating them much like feature releases in terms of testing. Most users are confident enough in the update releases to just "drop them in" without doing a lot of testing; now they'll be able to do so for a longer time in between feature releases.
These are not easy changes to make. We're still in the middle of figuring out a bunch of the details, so reality over the next couple of years might not exactly match what I've described above. Overall, however, we think that the improved focus and increased agility of the new release model will bring big benefits to the platform and to the Java community.
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 knowright 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.
Last Friday we posted the first of the Tiger Snapshotreleases to the web. Build 55 is available right now, and the plan is to post each weekly build until we reach the Release Candidate (RC) build. Unlike our milestone releases these builds receive only limited testing, so they're not for the feint of heart. If you'd like to live on the bleeding edge, though, then these builds are for you.
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.