Sun's Open Source Java

At the JavaOne conference held in San Francisco this past May, Sun announced plans to make Java open source. If you're not a software developer you may respond with a shrug of your shoulders and a "So what?" However, when you consider that since its inception in the early 1990's, Java has become a pervasive computing technology with more than 5 million developers and over 3 billion Java-enabled devices -- from cell phones to satellites -- it's almost certain that Java touches you in some way. Contemporaneous with this, open source software has also grown from a handful of pet projects by free-thinking university students to industry-standard technologies like DNS on which the entire Internet is based. Put these two together and we have a phenomenon difficult to ignore.

What is Sun's intention?

Sun already has a number of open source offerings, most notably their operating system OpenSolaris, and their contribution to OpenOffice.org. By making Java open source they'll be gaining an army of independent developers while positioning Java as the preferred language for cross-platform applications.

Because of the proprietary nature of Java, there has till now been some resistance by die-hard members of the open source community to include Java in their applications. One developer stated, "The open source community is not going to truly embrace Java until it is 100% open source, and Java is not going to see its full potential until the open source community completely embraces it and takes it as far as it will go."

The latest version of OpenOffice.org is a prime example of this resistance. While the core is written in C++, some features are written in Java. Those features may not function properly on a system that doesn't have Sun's Java Runtime Environment installed. And some users refuse to install the JRE because it's not open source.

An open source Java would have a decided advantage over Microsoft's .NET Framework which has no native Unix, Linux, or Macintosh support (there are some third-party ports available) and which is even less highly regarded by many open source programmers.

Compatibility is key

Sun has fostered an open relationship with Java developers since the beginning through the Java Community Process program. But while they've been open to suggestions and contributions from the Community, they've always retained ultimate control over Java. And with good reason; they're justifiably concerned that Java could become fragmented.

A few years ago Microsoft, taking advantage of some ambiguous wording in their license agreement with Sun, began publishing a Windows-only version of Java with their own extensions. That "Microsoft Java" threatened to defeat the "write once, run anywhere" philosophy on which Java was created. Sun responded with aggressive legal action, with the result that Microsoft excised Java from Internet Explorer and created its own programming platform, .Net and the C# language.

To prevent history from repeating itself, Sun would need to choose the open source license under which it releases Java very carefully. It is critical that they maintain compatibility. In his weblog, Jonathan Schwartz, President and CEO of Sun Microsystems, Inc., made the comment, "Compatibility is what creates the market Sun, and others, can monetize with network innovations, from software to hardware and services."

What about GCJ and other projects?

For some developers, Sun's announcement is a moot point; they already have GCJ, the GNU Compiler for Java. This fully open source tool compiles Java source code into byte code or native machine code, eliminating the need for Sun's JRE. But GCJ isn't yet complete; it's missing some libraries, particularly graphics APIs. Another promising option is the Apache Harmony project which has received code infusions from both Intel and IBM, and tacit approval from Sun. And there are others in varying states of development.

By adding its own hat to the open source Java ring, Sun could be seen as a competitor to these other implementations. But competition can be a good thing. Just as the various distributions of Linux have fostered rapid innovation for that operating system -- yet there's only one authorized channel for the Linux kernel -- so multiple distributions of Java could lead to faster bug and security fixes, more supported platforms, and better performance. So long as these various implementations of the Java specification pass Sun's rigid compatibility tests, there should be no problem with maintaining compatibility.

Does it matter?

By choosing to make Java open source, Sun ensures that the child can outlive the parent. If Sun held on to Java as a closed source, proprietary product, and if Sun was acquired by another company, it's entirely possible that the new owners could take Java in a different direction or even abandon it altogether.

However, for most developers, whether the Java engine itself is open source or not doesn't really matter. It's always been possible to create open source applications written in Java, as evidenced by the thousands of Java projects hosted on sourceforge.net. Sun's announcement will only ensure continued growth.