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.Desktop
class, 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
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.
The Early Draft Review version of the JSR 270 specification,
which governs the content of the Java SE 6 “Mustang”
release, is now
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.
Here’s a summary of the approved feature
list sorted by area, component, and feature name. For more details please see
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:
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
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.
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
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
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.