Ray Gans's Blog

Community: JDK Archives

Mustang and Dolphin... we'll miss you

Yes, we must retire some old friends. Management says it's time to drop these code names and develop a new project naming system around our open source model. Better now than after Dolphin get's firmly entrenched – and as for Mustang, well it's almost done anyway.

So with some sadness, we're walking Mustang out from her stable one last time to let her roam free in the meadows and we're opening the gate so Dolphin can return to the sea. Code names come and go and it's time to move on to our bright new future.

What has been Project Mustang on java.net will now be recast as JDK 6 (no surprise there I hope) and I'm happy to say we're launching JDK 7 on java.net today!

The mustang project on java.net has been redirected to the new URL https://jdk6.dev.java.net.

Our new project, JDK 7 can be found at https://jdk7.dev.java.net.

JDK 7 (formerly Project Dolphin)

We have posted build 1 on the JDK 7 download site (just a version string change from JDK 6 build 92). Plus by popular demand, we'll soon be hosting a Subversion repository of JDK 7 code from java.net as well.

We'll only be updating the JDK 7 binaries periodically for a month or two, since most of our efforts are still on JDK 6, but we do plan to start posting source and binary updates weekly again as soon as possible. New builds will track with improvements made to the JDK 6 release plus add additional enhancements and features over time.

Note that some javadocs still say Java SE 6 – we'll update them to Java SE 7 sometime during the next few weeks).

Wait... so how can Sun roll out a new project before it's been approved by the JCP?

I don't think anyone expects Java SE to stop at version 6! In anticipation of a future release, we are continuing work on enhancements to Sun's implementation that are covered by the Java SE 6 specification – things that were deemed too risky or disruptive to include at this time in the code base for JDK 6. This would include performance enhancements, bug fixes and other improvements (such as contributions made by developers) that we just didn't have time to get into JDK 6. Minor enhancements to the API may also be included – with the clear understanding that any change to the specification must be approved by the JCP before it can be included in the final release.

What about Open Source?

Laurie Tolson, VP Java Platform Group, gave an update to press and analysts yesterday about our plans to open source the JDK. Take a look at our new JDK open source community site at http://community.java.net/jdk/opensource to find out more and talk to us. We're interested in your thoughts and opinions about an open source JDK. Mark Reinhold and Danny Coward also tell about the latest in their blogs.

Update on Mustang, Dolphin and the JDK Community

The last few months have been exciting for Java SE with the many JavaOne activities and presentations, our announcement to open source the JDK, and getting beta 2 out the door. Let me tell you, it's kept us all very busy here at Sun! Things aren't slowing down either, so I'd like to give you a brief update as to what's going on.

Mustang

Dolphin

Open Source

DLJ and jdk-distros

javadoc Translations

Survey

• Demographics: Info about the survey respondents
• Interests: General interests of the survey respondents
• Transparency: How to increase transparency
• Rewards and Recognition: How to improve rewards and recognition
• Community Building: How to build a stronger community
• Participation: How to increase community participation
• Java Use: How the survey respondents use Java SE

We will use this data to make improvements to the JDK Community site as we move forward.

Thanks to all who have helped us take Mustang to where it is today. Your code contributions, testing and bug reports have been outstanding and it has been rewarding for us here at Sun to work together with you. We're looking forward to improving our relationship with you as we get into Dolphin. If you're interested in joining or just want to see what we're up to, please take a look at the JDK Community of projects on java.net.

Where we are with the JDK Community

It's been almost a year now since we started the JDK Community on java.net and I'd like to give a well deserved "Thank You!" to all of you who have participated and visited the site. As part of this thanks, I'd like to provide an update to where we stand and where we're going. I also want to invite anyone who is interested to take our survey to help us know what were doing right and where we can make improvements.

Over the past year Sun's goal for the JDK Community hasn't changed, we still want a vibrant environment where the developer community can interact with each other and with Sun engineering to help evolve Java SE, the JDK, and other related tools and technologies. In particular we want to attract developers who are passionate about the JDK and who are interested in collaboration.

To that end, here is what we've accomplished.

• Hosted the Tiger, Mustang, and (soon) Dolphin projects to provide source and binary snapshots of the latest builds & updates.
• Created and regularly monitored forums to address developer questions and feedback about the snapshots, contributed fixes and reported regressions.
• Linked research projects from the JavaDesktop Community that were relevant to the JDK community.
• Provided a home for over 30 research projects driven by both Sun and non-Sun project leaders.
• Ran the Crack the Verifier Initiative for the community to look for problems in the new type checking verifier and received 5 issues to be addressed.
• Currently running the Project Mustang Regressions Challenge Contest which received 87 submitted regressions that have led to 32 new bugs during the last 4 weeks. This contest runs through the end of March, so I encourage anyone who finds a binary compatibility problem in Mustang to check this out -- you might win a sweet Ultra 20 workstation.
• Drove interest and feedback for the Mustang weekly snapshots through blogs (aggregated list), articles & news, and bug fixing and collaboration opportunities.
  • Roughly 70,000 downloads of weekly Mustang snapshot binaries since they were first posted in early November 2004.
  • Roughly 14,000 downloads of weekly Mustang source snapshots during the same period.
  • 448 bugs reported against these snapshots and 336 of them added to the bug database.
  • 181 bug fix and enhancement contributions to the Mustang project with 34 integrated into Mustang and 3 back-ported into Tiger updates. We want to get these numbers up and are working hard to evaluate and incorporate as many of the rest as possible.

• 1,153 registered members to community projects covered under the Java Research License (JRL).
• 321 registered contributors to these projects.
• 942,483 visitors to community project pages.

Trends are up too. We've lately seen a huge growth in monthly visitors to JDK Community projects (over 4 times more visitors last month than we had in July) and doubled the number of Mustang contributed fixes during the last 2 months.

I'm sure there is more we can do to improve relevance and function of the JDK Community and its projects. We have lots of ideas, but want to hear from you as well. We'd like to know what's missing, what we're doing right, and how we can improve the site for regular and occasional visitors.

To help in this task, we developed a survey to collect some feedback. The survey contains 25 questions (many of which are optional for feedback) that should take less than 15 minutes to complete. It doesn't matter how often you've visited or participated in the JDK Community, we want to hear from you. Even if you've never visited the JDK Community pages before, take a look and then let us know what you think.

You can find the survey here. Thanks for participating!

Where We Are With the JDK

Roadmap for Mustang

Here is where we stand now with Mustang and Dolphin (Java SE 7):

1. The draft Mustang feature set has been approved by the JSR-270 expert group. See Mark Reinhold's blog for more information.
2. Sun currently plans to release a Mustang beta in early February.
3. The Dolphin project is expected to be opened in spring 2006.
4. Weekly Dolphin snapshots of source and binaries will be released in parallel with Mustang snapshots. New fixes put into Mustang will also be put into Dolphin.
5. Sun will likely release a second Mustang beta in summer 2006.
6. Mustang is planned to ship in autumn 2006.
7. Mustang updates will be released every few months after Mustang ships. These updates will contain mostly bug fixes and performance enhancements (i.e., no API changes).
8. Dolphin is scheduled to ship during calendar year 2008.

These are our current plans. They may change. Let me say that again, "The schedule may change..." but it's what we're working towards now. We will let you know more details as things move forward.

So why will Mustang slip to autumn?

At this time, all the expected Mustang features are nearly complete. The next step is massive testing and targeted bug fixing on all levels (i.e., spec conformance, binary compatibility with prior releases, performance, robustness, etc.). It takes a long time and the efforts of people both inside and outside Sun to ensure the new features work properly and verify that we haven't broken anything in the process.

Sun's Java SE Quality organization has been in full gear for months and it will take many more months to prove the code is ready for final release. The developer community can provide tremendous assistance as well by testing existing applications against the snapshots and investigating new features -- then letting us know when problems are discovered.

The Mustang beta will be based on build 59 with some tweaks to clean up several bugs. This beta has been heavily tested so you may be more comfortable running your applications against it rather than a snapshot release (though to be honest, most of the latest snapshots have been very robust). However, the beta is missing some improvements that are included in more recent builds (which can be found on the Mustang changelog).

What does this mean for developer community fixes?

Update releases generally address bugs or performance problems that were missed (or deemed too risky to fix) during beta. They are not "dot-dot" releases and don't include changes to the API. When it makes sense and testing resources are available, Sun may choose to back-port certain bugs fixed in new releases to updates of prior releases (for example, 3 bug fixes contributed by the community for Mustang were included in the latest Tiger update). For this reason, when we receive a minor fix late in the development cycle, it may be better to wait than take the risk of accidentally destabilizing code that is otherwise working well. Waiting a few months longer to more closely evaluate and test the impact of a proposed fix will in some cases be the most pragmatic way to incorporate (or reject) it.

So keep those fixes coming -- here's how and why. All contributions are appreciated and can really help to make Mustang a better release for everyone.

What about Dolphin?

The Dolphin project on https://dolphin.dev.java.net is currently being prepared to manage snapshot downloads and share other project information. Some things such as existing forums may be shared with the Mustang project and/or renamed to minimize confusion and unneeded duplication. We should be ready to release source and binaries for build #1 in spring 2006.

So where should developers focus their efforts? The Tiger project is the place for current stable release work and research; the Mustang project will have the role of pending release with opportunities for testing, bug fixing and additional research; and (when made available) the Dolphin project will be available for proposed cutting-edge development and enhancements.

So please stay tuned, we have several Mustang-related activities planned for the JDK Community during the next few months and hope you'll join with us to help finish off Mustang and get started on Dolphin!

Java Research License Update

Thanks to thoughtful comments and questions from the community and great feedback at Java One, Sun has revised the Java Research License (JRL) to address several concerns that have been brought to our attention -- in particular with how it affects open source developers. As before, it is Sun's purpose to make its code easily available to developers under JRL for research and collaboration purposes and to not get in the way of other efforts. In addition we want to make the license possible for a non-lawyer to understand (which believe me is a challenge!) so people don't needlessly worry about accepting its terms. The changes we made are really just clarifications and some cleanup to the existing language, so no java.net projects using this license should be affected. The upshot of the update, we hope, is that more people will now be comfortable about participating in JRL projects.

So what's changed?

The definition of Modifications was clarified to ensure that the JRL is only concerned with changes or additions to Sun's code. The JRL does not prohibit you from doing any work alone or under another license (e.g., an open source license) as long as such work is done independently of JRL code. The Purpose section of the license was also expanded to better reflect this point, i.e., that code made available under the JRL is not intended to be used for consultation purposes on independent efforts. While this may seem obvious, the fact that it wasn't clearly stated has led to some questions. And don't worry, we did not back off on your residual rights. No one becomes "tainted" by examining code under JRL. Your memory is not contaminated and the JRL does not prohibit you from later participating in other projects after working with Sun's code -- in fact you may remain a JRL licensee in good standing while doing so.

We did some cleanup as well. The term "specifications" was removed from the definition of Technology (i.e., source and object code) since specs are generally covered under their own licenses and not distributed under the JRL. An address is now included where one can send notice in the unlikely event that he or she wants to terminate the JRL. We also clarified that termination of your JRL requires you discontinue all use and distribution covered by the license (which was backed up in the rest of the license, but not well stated in the previous termination section).

Notice too that the sections on Residual Rights and Third Party Software were replaced with language used in other Sun licenses for consistency. This new language is the same in intent as the old, but hopefully a little easier to read and understand.

If you'd like to compare the updated JRL to the old one, you can find it here.

I think the JRL is a good license and those interested in the licensed technology should have no qualms about its terms. We've tried hard to ensure that the JRL does not create a barrier for anyone who has used or examined the code and later wants to work on another project -- including an independent implementation of the same technology. Maybe it won't work for everyone (heh, and what license does?) but I believe it will meet the needs of the great majority of developers.

And there's more...

The JRL FAQ has been updated to answer additional questions and Sun has published a couple articles on the JDK Community site on java.net to discuss several issues in more depth pertaining to Java SE. The first is a note that addresses common questions from developers about Sun's Intellectual Property (IP) and the creation of independent implementations of Java SE (especially with regards to the Apache Harmony project). The other article provides a further discussion about "tainting" concerns over Java SE source code. Check them out and join us and other developers on the Mustang Project to create the next version of Java SE.

Again I'd like to thank those in the developer community who have kindly brought these issues to our attention. I hope this JRL update and the two articles will open more developers to work with Sun and to help move Java technology forward.

-Ray

Java Internal Use License (JIUL) released for JDK 5.0

I am very pleased to announce that Sun has released a new license for the JDK called the Java Internal Use License (JIUL or "jewel"). This license lets developers easily make changes to the JDK for internal deployments. It's free, click-through and should be easy-to-read by non-lawyers.

JDK 5.0 source is available now under both the JIUL and the Java Research License at the tiger project in the JDK Community.

End-users of Sun's implementations of J2SE 5.0 now have the ability under the JIUL to fix any critical issue in the code that adversely affects their business operations. In addition, Sun will waive the commercial requirement to pass the Technology Compatibility Kit (TCK) for J2SE (a.k.a. the JCK) as long as all code changes are made with diligence to assure the resulting implementation remains true to the specification and that its use is restricted to the licensee's internal business or organization.

What? How could this be? Hasn't Sun proclaimed since the dawn of Java, "Thou shalt only have compatible implementations before thee!" And now... Sun is giving people the right to change the JDK without verifying that compatibility?

Well yes, and no.

Sun is not backing away from compatibility. In fact, a passion for Java compatibility should be a prerequisite for any company or individual who enters into the JIUL. The purpose of the JIUL is to address a specific business need of Sun's customers who tell us that while compatibility is critical to both Java technology and their businesses, they also need the ability to fix critical bugs or performance issues in an emergency.

So why drop the requirement to pass the JCK?

The JCK is not designed for end-users, but rather for J2SE implementers who are intimately familiar with the operation of their code. Few businesses need to understand all the intricacies of the JDK runtime and few operate in work environments that make use of every J2SE feature. However, all features must be set up and successfully tested as part of passing the JCK. For this reason, the cost in time and resources necessary to understand, set up an appropriate test environment, and then pass the JCK is just not practical for most businesses.

The JIUL runs on the "honor system." Sun trusts that licensees will make changes with great professional care so as to limit the risk that compatibility is compromised. Sun understands too that even the best of intentions may fail which is why all JIUL-based J2SE implementations must remain strictly within the confines of that licensee's business or organization.

To be clear, the JIUL is not a general purpose J2SE implementation license. Sun has commercial licenses for those who wish to distribute their implementations (and such licenses do require the code passes the JCK). Think of the JIUL as a safety net. It provides peace of mind when things are good and more control over managing your IT operations in times of a business emergency. I hope you never have to use the JIUL, but if the need ever arises, you'll be glad it's there.

This work is licensed under a Creative Commons License.