 |
September 2004 Archives
Tigers and Mustangs and Dolphins, Oh My!
Posted by mreinhold on September 30, 2004 at 02:18 AM | Permalink
| Comments (3)
Tiger is done.
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.
Tough and Trustworthy Tigers
Posted by mreinhold on September 01, 2004 at 03:26 PM | Permalink
| Comments (1)
The Tiger Release Candidate shipped
earlier today.
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.
|