Geir Magnusson expresses surprise that the collaboration site for Dolphin JDK 7 was recently unveiled despite the fact that Mustang JDK 6 hasn’t shipped yet.

I’m not sure why this is a surprise; it’s really just good software engineering.

Toward the end of any big software project the rate of change in the code base must be throttled down dramatically in order to achieve the stability and quality required in the final product. The rate of change in the JDK 6 code is far less now than it was even just a few weeks ago. As of today, heading toward the release-candidate build, the core release team is looking at a short list of a couple dozen showstopper bugs. Once we fix just those bugs then we’ll start several weeks of intensive testing, and—if all goes well—we’ll ship that as the first release candidate.

Now the world doesn’t stop turning—and developers don’t stop hacking—just because JDK 6 is in stabilization mode. Engineers both inside and outside of Sun are already working on fixes and features for JDK 7, so the question arises: Where should those changes go? We could ask people to keep their changes to themselves until we’re good and ready to open up the JDK 7 workspace (i.e., source repository), but our own experience suggests that this is a pretty bad idea. This approach basically results in lots of little forks of the code base, and reweaving all those forks together when the official workspace opens up can be a pretty painful process.

So the JDK 7 workspace was created internally a few weeks ago, and the first build was promoted shortly afterward. (The only changes in that build were to version strings and such.) Not many changes have been integrated since then, but that’s no reason not to make the sources available for collaborative development even though they’re not yet under an open-source license. We’ll be promoting JDK 7 builds every two weeks or so and doing minimal “warm and breathing” testing on them until JDK 6 ships, at which time we’ll switch to weekly promotions and the full force of our mighty quality team.

Geir is also surprised that the JDK 7 code isn’t licensed as open source, but I’m not sure why that’s a surprise either. We can hardly put our source code under an open-source license when we haven’t yet chosen which license we’re going to use. Rest assured that once that choice is made we’ll then make the (unencumbered) code available under that license.