|
The future of Java will continue to depend on a strong community
August 15, 2006
URL:http://www.drdobbs.com/jvm/the-future-of-java-part-2/192100004
Eric Bruno is a Java consultant, author of Java Messaging, and Java blogger for Dr. Dobb's. He can be contacted at [email protected].
In this installment of the "Future of Java" series, I look at the Java community of developers, and Sun's very first move towards open source Java. I recently spoke with Ray Gans, a program manager for Java SE at Sun Microsystems, regarding Sun's role in the Java community environment starting with Java SE 6 (Mustang). What began as Project Peabody, where Java SE developers posted their code weekly for the world to download and see, is arguably one of the first steps Sun has taken towards open-sourcing Java.
Project Peabody is now known as the JDK (or simply Java) Community. Moving towards a participant model for future Java development has given Sun deep insight into both the open source world, and the world of Java developers. Listening to developer feedback provides benefits to both Sun, and the developers who provide that feedback, and in turn has led to a major culture change within Sun. Let's explore this change in more detail.
In November of 2004, Sun decided to give developers access to the source code for early builds of Mustang (Java SE 6) on https://mustang.dev.java.net. People were encouraged to download the code, look at it, and provide feedback. Binaries were made available under a special click-through evaluation license, and the complete source code was available through the Java research license. A lot of excitement was generated right from the start, with over 10,000 downloads of the code drops per month.
In March 2005, the program was expanded, and a number of projects were opened up to the JDK community through http://java.net. People had a place to discuss the code, create prototype and research projects online, provide general code enhancements, and contribute bug fixes. If you were at JavaOne this year, you might remember that special recognition and a Duke's Choice award was given to Brian Harry for his outstanding contribution to the Java SE project (114 bug fixes).
If you Sun management why they have put so much time, energy, and resources into opening the Java SE source code to the community, the answer is simple: to provide an environment for information to go both ways (both to and from developers). The goal was to remove barriers with, namely, developers, and to show that Java was built on a good source code base. Even for those not interested in the source code, the availability of early binaries and a site where feedback was welcomed has provided an avenue for people to give their opinion on Java's direction and future.
All of this work has proven to be helpful to both Sun and developers. A dialog between the parties has been opened, and the potential for "surprises" regarding the future of Java has been reduced, if not completely removed. This is further proven by Sun's encouragement and funding of its internal resources (those working on Java) to actively blog about Java SE 6 and 7 (Mustang and Dolphin, respectively).
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.
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.
In April 2006, Sun sent a survey to members of the Java community in order to solicit feedback on the direction Java was going, or should go. The survey asked for areas to be improved or changed for the better. In return, Sun has invested in the community by encouraging its developers to actively blog about the future of Java. At sites such as http://weblogs.java.net, you can read blog entries from the actual people who design and build the Java future. Again, the information flow goes both ways.
You can read from an aggregated view of all Sun-sponsored, Java-related, blogs at http://planetjdk.org. Here, you will find entries from developers of Mustang, NetBeans, and the Glassfish project.
Don't let the future of Java escape you. Become an active part of the community, if you haven't already, by visiting https://mustang.dev.java.net and http://community.java.net/jdk often. Be sure to also sign up for a Sun Developer Network account (http://developers.sun.com), and to become a Java Community Process member.
Sun was actively pushing people to sign up for this network of communities at JavaOne this year. Why? Because it's important to the future of Java to ensure that a healthy community of developers exists. It's also important that the future is guided by individual developers like you, not just corporations or other entities. By helping to guide Java's future, Sun is doing its best to ensure Java's success for years to come, and you're doing your part to ensure that Java will continue to be what you need it to be in the years to come.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.