Graham Hamilton's Blog

October 2005 Archives

Help Crack The Java Verifier

Sun is asking the developer community to help attack the new bytecode verifier in Mustang. Here's some background on how and why the community can help here.

In developing Java SE 6 ("Mustang") we have adopted a more open, community-based, development model. As part of that we are releasing complete binaries and sources for all our weekly Mustang builds at mustang.dev.java.net and we are also recruiting community contributions into the release.

In previous JDK releases we had waited until the releases were functionally complete and stable before we released our first binaries as official betas. And we waited even longer (often until final release) before making available full source for the releases. After all, why bother to release incomplete builds or non-final sources? We all want to be seen and judged on our best work, not on our rough drafts, right?

Well, we were partly right and partly wrong. There are many customers who are only interested in seeing the final, stable end product. They want to download something that will work well for them and they don't want to see the intermediate development steps. That approach is perfectly valid and makes a lot of sense for many busy customers. And we don't want to delay or distract those customers.

However, it is also clear that there are many developers who would like to act as collaborators in helping to make Java SE better, both by reviewing the work in progress and by actively contributing code and insight into the release. For that community, exposing rough drafts makes perfect sense. These are our coauthors who are helping us create the final work. That is why we created the mustang.dev.java.net collaboration site so we could expose interim builds, get feedback, and incorporate changes from the community.

We've already been receiving a lot of feedback on Mustang based on the various weekly builds. That has been much appreciated and has been helping us to tune and adjust the release as we go along. Thank you.

But now we have come to a particularly scary moment and a particularly important opportunity for the community to contribute to Mustang development. As part of Mustang we will be delivering a whole new classfile verifier implementation based on an entirely new verification approach. The classfile verifier is the very heart of the whole Java sandbox model, so replacing both the implementation and the basic verification model is a Really Big Deal. See Gilad Bracha's blog for an overview of the new verifier plus links to the spec. The new verifier is faster and smaller than the classic verifier, but at the same time it doesn't have the ten years of reassuring shakedown history that we have with the classic verifier.

The new verifier led us to an interesting test of our new development philosophy. Should we delay exposing the new verifier for as long as possible? Or should we push it out, advertise it, and ask for the community's help in reviewing it? Well, I will confess that many of us had an initial fit of the heebie-jeebies about publishing the source code for the new verifier. "But what if someone finds an ugly security hole?" Gasp!

But that question does kind of answer itself, doesn't it? If someone spots a problem we can fix it and we can fix it before we finalize the release. Happiness!

We think the new verifier model is sound and we are taking various steps to review the actual implementation code. But the more eyes that can look at this before it goes into production use, the better.

As a result, Sun has launched the Crack the Verifier initiative. Read the article for more details, but broadly Sun is looking for security experts and astute hackers in the Java community who can help review the new verifier and help discover any potential holes in time for them to be fixed in Mustang.

I hope people will rise to this challenge. This is definitely a case where broad community involvement can trounce what any one individual company can hope to do on its own. I hope this will be an opportunity to demonstrate that community-based development can really help improve a core area of a key Java technology.

Now, I'll also be extremely happy if what happens is that a lot of people look at the new verifier and no one finds any holes. That will be a good outcome! But if there are any holes, let's find them now...

Java SE and the Google Toolbar

Sun has announced an agreement with Google to distribute the Google toolbar along with consumer Java SE downloads from java.com. Here's what is happening and why.

The Background

We've been working for several years to increase adoption of the latest Java SE Runtime Environment (JRE) among home consumers on the internet. We've been pursuing two tactics. First, we've been working with the major PC hardware vendors to include the JRE on new PCs. That has been very successful - a majority of new PCs now ship with the JRE preinstalled, which is great. Second, we created the java.com site as a new consumer friendly site where consumers could easily download the JRE, at zero cost. That has also been wildly successful and we are getting a very high volume of consumer downloads (well over ten million a month).

That's been great progress, but of course we are eager to find even more ways of reinforcing Java technology on the desktop. At the same time, we want to be careful not to do anything that would be onerous or unpleasant or otherwise discourage consumers from using Java. And even more importantly, we want to be very sensitive to the needs of Java developers and ISVs and we want to avoid changes which might interfere with developers' ability to use or distribute Java.

In searching for possible opportunities, Sun got connected with the Google toolbar team, who were looking for ways to encourage adoption of the Google toolbar. Our goals seemed very compatible. Like Sun, Google was extremely concerned to avoid doing things that would mislead or annoy or disrupt consumers, which was very reassuring.

It probably also helped that many of us are avid users of google.com and that Google in turn does a lot of Java development and contributes to various JCP expert groups. (Did you know that Google is a JCP Executive Committee member?)

What We're Doing

Here's what we have announced and what we will be rolling out over the next few months.

We will be adding some options to the Windows JRE installation from java.com. These options will allow downloading and installation of the Google toolbar (and possibly other Google tools in future) as part of the Windows JRE installation. I want to emphasize that these will be options. If someone doesn't want these tools they can easily opt out and still download and install the JRE.

Our core principle here is to avoid forcing anything on anyone. So we will take care to make it clear to end users what is going on and we won't force the toolbar or other tools on people who don't want them. (Yes, I know that probably sounds kind of obvious, but we don't want any misunderstanding on that point!)

If someone wants to uninstall the Google tools they will be able to do that, while leaving the JRE installed (and vice versa). Again, this is about allowing reasonable end user choices, with no hidden "gotchas".

These changes are primarily focused on the consumer JRE downloads hosted from java.com (although they may also affect some related "online" JRE installation bundles on java.sun.com). The way that the "online" installers work is that a small initial installer is downloaded and it then downloads additional material depending on which options the end user selects. So, as with other optional material, the Google tools will only be downloaded if the end user actually selects them.

Note that we are not requiring developers or ISVs to redistribute the Google toolbar with their applications. In particular, the redistributable JRE bundles that developers can redistribute with their apps won't include the toolbar.

Similarly, enterprise system administrators can continue to get redistributable JRE bundles from java.sun.com for use in deployments within enterprises, without the toolbar.

We are also looking into the possibility that in the future we might offer Google toolbars during JRE auto-updates. If we do go down that route we will again be very careful to make sure that people can opt out and that there are no surprises or gotchas.

Conclusion

Hopefully this will be a good experience for everyone. Consumers will get an option to install useful search tools and Sun will get some extra help around Java development and deployment, especially as we head towards the new Java SE 6 "Mustang" release.

Finally, I'd like to offer Big Congratulations to Thorsten Laux, the Java SE Desktop Engineering Director for figuring all this out and for driving and closing the agreement. Thorsten is a key champion of desktop Java and he has been relentless in looking for opportunities to boost Java desktop adoption.

This work is licensed under a Creative Commons License.