Java Licensing
Creating the Java community process had a pleasant side-effect of helping to straighten out some issues around licensing. At the time, Sun took a look at the barriers the licenses put up that made it harder for those who wanted to redistribute the Java runtime environment (JRE). Although Sun does charge companies who embed Java within their products (and hence redistribute it), there are occasions where charging a fee is not appropriate.
For instance, it's in Sun's best interest to allow Linux distributions, and the companies that provide them, to redistribute the JRE and JDK freely. This ensures that Java is available to people out of the box, without requiring a secondary download from the Sun site. For this reason, the Distro License for Java (DLJ) was created.
Because of the license changes, OS distributions such as Ubuntu, Gentoo and Debian (distributions of Linux), NexentaOS (a hybrid OS with an OpenSolaris kernel), the Schillix and BeleniX versions of OpenSolaris, and GNU tools and applications are able to include the JRE and/or the JDK freely. For more information on the DLJ, and the full list of Java redistributors, visit https://jdk-distros.dev.java.net.
Java Community Contests
Besides access to bi-weekly drops of source code and binaries, members of the Java community have been invited to take part in various contests and surveys that Sun has sponsored. Take, for instance, November 2005, when Sun was preparing a release of a brand new version of the Java Type Checking Verifier tool as part of a preview of Java SE 6. The Type Checking Verifier is at the heart of Java security, and checks the bytecode for a class to ensure that all execution paths and data accesses are safe and secure.
As you can imagine, changes to the Type Checking Verifier can be risky, as security and backwards compatibility must be assured. To help ensure that the new Verifier was tested thoroughly, Sun decided to call upon the Java community by creating a contest. The contest was called "Crack the Verifier". The challenge was for members of the community to examine both the new Type Checking Verifier specification and the implementation to find ambiguities, holes, and/or errors.
Those who found errors in either the specification or implementation were given special recognition, both on Sun's web site, as well as at JavaOne 2006. Participants were asked simply to identify problems; they didn't even need to submit a fix. For most, receiving recognition at JavaOne in front of their peers and colleagues is very rewarding.
In another contest, held in February and March of 2006, members of the community were asked to find regression bugs in the beta release of Java SE 6. Regressions are classified as valid Java code that executes properly in one version of Java, but fails to execute properly in a newer version of Java. In this contest, prizes were given out: five Sun Ultra 20 workstations were to be rewarded to the first five valid (non-duplicate) regression submissions. There were over 130 regressions submitted (including duplicates), and by the end of the contest, around 70 true regression bugs were identified.
These contests show the other benefits to opening Java SE to the community. Sun was able to leverage the large number of Java users to identify and fix problems early in a development cycle, and members of the Java community have received recognition, and in some cases, valuable prizes in return.
