We've published 5 Mustang builds so far. But there hasn't been much to write home about. We've made some steady progress, but no sweeping language changes, no major new library packages, no ports of the virtual machine to new platforms. We haven't even implemented all of the suggestions from this forum. What's taking us so long?

It's probably worth giving people a heads up on how the Mustang release is going to progress between now and when we declare it done.

Right now we are mostly fixing bugs we didn't get into Tiger. (You'll see, this will happen again at the end of Mustang, with fixes we'll push off to Dolphin.) We're also cleaning up code and other small chores while we work out what new things to get into Mustang. There are lots of sources of good new ideas: while we were working on Tiger we talked to a lot of people about what we should do next, the Java community process has some big ticket items, our licensee partners have porting and tuning concerns, this forum is full of smart people, etc. We are also starting to field feedback from people who are using the new features we put into Tiger. All that goes into planning for Mustang. There's no shortage of bug reports, RFE's, suggestions for tuning, good ideas (and some not so good ones). We have a long list of things we want to do; the trick is figuring out what we can get done well in Mustang. Soon the planning will die down and we engineers will be heads down writing code.

But for you watching the snapshot builds come out: a note of caution. Things will probably get rough before they get better. All that new code will come with unit tests, but those don't catch all the bugs. We have a whole quality engineering team to write additional tests, but they are coming up to speed on the new features too, and sometimes they read the specs more carefully than the developers do. There are the JCK tests to write, too. QE is always behind when whole new API's are in flux. We have a quality assurance team to run all the tests on all the instruction sets and operating systems we support, in various locales, on all sorts of weird graphics cards, etc., but it takes QA a while (weeks, months) to cover the more obscure variations.

Different groups have different strategies to balance working on new features and fixing bugs. Some teams have some designated bug fixers for a release, to leave other people free to focus on new features. Some groups have everyone fix bugs in and around working on new things. Some groups have people now working on features that we know won't be ready until Dolphin. And it's not like we have a set list of bugs to be fixed that we just work our way through. Sometimes we introduce new bugs in spite of our code reviews and unit testing, and you might trip across bugs those in the snapshot releases. (And you'll report them, I hope, so that we can get them fixed.)

Probably what you'll see in the snapshots -- unfortunately -- is a temporary decrease in quality. And steps backwards in overall performance, footprint, startup time, etc. Oh, the snapshots are not as bad as all that. Those builds have been through individual engineer and group testing, integration testing with other groups, and as much testing as we can get in while still getting the snapshots out to you in less than a week. Mustang might be different because we are trying some new ways of managing things: e.g., putting the snapshots out so people can try them earlier and file reports on bugs they find. And, we'll be accepting -- real soon now -- bug fixes and features from you java.net folks. But I thought I should warn you that you might not see continuous improvement. The advantage of the snapshots is that you get to see the new features first, try them out, exploit them in your code, and give us feedback and suggestions for improvement. Things will get better.

At some point the axe will fall, and new features won't be allowed into Mustang. (Well, it's not as sharp a line as that. There are business reasons, and late JSR's, and pressure from one or another of our valued licensees, etc., that make this process a "slush" rather than a "freeze".) The idea of drawing a line is to give the QE folks time to finish writing tests for the features, and to give the QA folks time to run all their combinations. The documentation folks come around and figure out what's new and how to explain it in the release notes and web pages. New development doesn't stop, but it does slow down. People who didn't get their features into Mustang switch to getting those features into Dolphin. But finding and fixing bugs becomes a higher priority. And the review and testing bar gets higher for any changes. Also, once the release settles down we can do integrated performance analysis and work on other aspects of quality we can't do until we know what we are working with. So later in the release cycle you'll see a marked improvement in quality.

At some point, the bar for putting back changes gets so high that we'll turn down even obvious bug fixes that wouldn't have been given a second thought early in the release. Those will go into Dolphin, and then get back-ported to the updates to Mustang. (How can I be thinking, now, about updates to Mustang? Because the big wheel goes around, with the little wheel inside it.) And we'll be asking around again about priorities and features and what we should do next.

I hope that gives you a sense of what to expect in the snapshot releases and how we might deal with suggestions -- or code -- you might contribute.

Don't look for flying cars in the first few snapshot releases. They'll be along later.