Graham Hamilton's Blog

Stabilizing the Tiger Release

In response to my recent blog on the Tiger Release Candidate, I've had a few people follow-up on specific bugs they'd like fixed. Now, whenever I see any specific bug description I always have a quick surge of frustrated empathy and I want to rush out and make sure it gets fixed asap. But then I take a deep breath and think of the larger picture...

Overall, we think Tiger is on track to be our highest quality release ever. Happiness! But unfortunately that doesn't mean (and can't mean) that it is bug free.

There is an agonizing tension in getting to high quality. To achieve stability, you have to become really paranoid about change management, especially late in a release. Since beta1 we have been increasingly cautious in bug analysis. We've tried to make sure the key bugs get fixed, but we've also deferred some bugs, in order to manage the rate of change and to make sure we keep a high level of overall stability. Some of these may get addressed in the Tiger update releases (5.0_01, 5.0_02, etc.).

In some of our early JDK releases we were aggressively fixing lots of bugs even very late in the release. Well, unfortunately, that didn't actually lead to high quality releases. Every bug fix is also a bug risk, even for those small fixes that "are clearly totally safe". Our history is that even heavily reviewed "totally safe" fixes sometimes aren't.

I'm sorry that not every possible bug fix has gone into Tiger. But we are doing a balancing act and the engineering teams have been carefully assessing all the candidate bugs. I know priorities can look different from different angles (especially if a given bug is interfering with your app!) but we've been trying to be thoughtful and to balance for the overall community good. Tiger contains a lot of important new features and also a lot of significant bug fixes and we want to deliver it to the community in a safe and timely way. That requires a driving focus on stabilizing the release and thus on progressively clamping down on change. I know this is an imperfect process, but we try to make the best choices we can.

Our main concern at the Release Candidate stage is to Not Break Anything(tm). The goal of RC is mostly to discover if we've had any significant "accidents" due to the fixes introduced since Beta2. Right now we are mostly seeing the RC status we expected. Overall we have extremely high quality, but with some previously diagnosed bugs.

RC is suposed to be essentially the final bits. The Sept 30th target ship date leaves room for one last respin, in case we had introduced some major late-breaking problem in RC. But if there are no critical show stopppers we might skip the respin and ship a little sooner.

                                                                                                              - Graham

Comments

• Well said.
  Every bug fix is also a bug risk, even for those small fixes that "are clearly totally safe". Our history is that even heavily reviewed "totally safe" fixes sometimes aren't.

  Yes! Yes! Yes!

  Posted by: bertbates on September 08, 2004 at 10:20 AM

• While we're discussing bug fixes...
  This would be a fine thing if only Sun would fix bugs quicker. The average turnaround time on bug report -> bugfix used to be two years. Now it's slipping to something like five years.

  Lets be frank, something has major has to change. Tiger is indeed a big *technological* step forward but Sun has to deliver more than technological solutions to the problem of Java development. Keep control of the code all you want .. I don't mind .. but make it easier for end-users to work with Sun engineers and get patches into Java releases quicker. People are dieing to submit patches if only Sun would let them.

  Posted by: cowwoc on September 08, 2004 at 10:37 AM

• Winlaf: Nice example
  Suppose you know the WINLAF project. It is trying to fix subtle differencies between Swing Windows XP LookAndFeel and the real Swing GUI. It claims the ambition to be merged with JDK one day. However in our recent project I had to disable some parts of WINLAF because of strange behaviour.

  Posted by: vtec on September 09, 2004 at 12:25 AM

• thanks for the explanation
  hi,

  thanks very much for the explanation - it is very good to hear that there are decisions being made not to do things rather than them just not happening or not registering (sorry if that sounds offensive!, but if your only point of contact with what is going on inside the JDK/JRE is via websites - then its easier to assume something is not happening than it is to assume it is)

  i can remember someone high up in Sun giving a talk and saying that Java had reached the point where it is "fast enough" and that future releases would put a much bigger emphasis on stability

  is this what we starting to see now? it would be interesting if any quantitative data on the "stability" of java could be made available..

  thanks,
  asjf
  ps. bringing the discussion from the general to the very specific once more.. this bug/rfe has been open 7 years

  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4057701

  Posted by: asjf on September 09, 2004 at 03:12 AM

This work is licensed under a Creative Commons License.