The Sun Also Writhes

The idea seemed so promising for developers: Sun Microsystems planned to use a standards commission, such as ECMA-European association for standardizing information and communication systems (formerly ECMA—the European Computer Manufacturers Association), to standardize the Java programming language. But for the second time in 8 months, Sun stopped the standardization process. At the December 1999 Java Business conference in New York, Patricia C. Sueltz, president of Sun's Software Products and Platforms Division, announced Sun's plan to remove the Java 2 Platform, Standard Edition (J2SE) from the ECMA standardization process. Sun gave no prior warning about this removal. The move caught many industry heavyweights that have a large investment in Java (e.g., IBM) by surprise. Sun's action is likely to have repercussions in the industry that will resonate throughout 2000.

Five years ago, when Sun released Java, the new language was an industry sensation with its unique value proposition: Write Once, Run Anywhere. A properly implemented Java program can run on any OS or on top of any program that runs the Java Virtual Machine (JVM), such as Microsoft Internet Explorer (IE) or Netscape Navigator.

Most Java implementations are Internet-related, and these implementations work provided that the JVM conforms to the proper criteria. On the client side, Java applets are slow, but on the server side, Java applets shine and attain the utility of the language. Java is ideal for the e-commerce era of heterogeneous networking, and that fact is why vendors support it.

Sun uses a modified open source model, the Sun Community Source License (SCSL), to provide Java to the programming community. Sun lets developers employ Java for undeclared use, but the company requires developers to share their work and improvements to the language. In turn, Sun's licensee, the Java Community Process group, adds the improvements that the group approves to the Java standard.

At the same time, Sun heavily branded, copyrighted, and trademarked Java. For example, Sun requires Java book publishers to sign its licensing agreement.

Sun's licensing has been a sore point in Java's developer community for some time. And recently, Sun introduced a royalty charge. Now, when you offer a Java application commercially and use the Java logo, you pay Sun a small percentage of product sales for branding. For example, Sun requires a 3 percent fee from revenues for commercial applications that use its recently released Java 2 Platform, Enterprise Edition (J2EE). This branding fee, along with the standardization problem, generated an interesting letter from Rod Smith, IBM's vice president of Java Software. In the letter, Smith said that IBM's Java group isn't happy with this fee, so IBM won't brand its Java products. (To see the entire letter, go to http://www.ibm.com/developer/features/ibm_commitment.html.)

To Sun's credit, the Java development system has worked reasonably well in the past without a standards body. Most people will agree that Sun has properly promoted Java, and no one can argue that Sun has acted with less than missionary zeal to keep Java pure. The problems are that Java has become much bigger than Sun and that developers outside of Sun make 75 percent of Java's improvements. Large vendors have poured big money into the Java carafe, and Sun is having a hard time keeping the lid on. Some large developers would like to move the language in directions that the Java Community Process group might not endorse.

Large software vendors, such as IBM, want Java placed under a standards body to protect the investment they've made in Java-based products. Sun planned for ECMA to serve as this standards body. Sun had hoped to negotiate the ECMA certification into an eventual ISO (International Organization for Standardization) 9000 international standards certification without going through the ISO's Publicly Available Specifications (PAS). In the PAS process, other ISO members, such as Microsoft, could comment on and influence the Java specification.

Sun contends that tight control of the Java specification is necessary to prevent multiple platform-specific JVM versions from appearing. Upon pulling Java out of the ECMA process, David Harrah, group manager of public relations for Sun Software Products and Platforms, said, "We were told that the ECMA was going to publish the specification but that the group wouldn't hold any kind of copyright on it, which would let companies create incompatible derivatives."

In 1999, Microsoft's attempts to extend Java on Windows led Sun to file a suit (which is still in progress) that claims Microsoft violated its Java license. The net result of this lawsuit is that Visual J++ (VJ++) might disappear from Visual Studio (VS).

Analysts expect Sun to make another attempt to place Java into a standards group, but no one can guess which group at this stage. Many Sun employees question whether standardization is necessary, so Sun's commitment to Java standardization isn't clear.

Sun's exit from ECMA has several committee participants examining the possibility of creating a Java standard without Sun. According to analysts, such an attempt (e.g., using previously published work, reverse-engineering Java) would fragment the Java community and capture only a fraction of the developer community.

Michael Wheatley, chairman of the ECMA TC41 (Platform-independent computing environments) committee, works for IBM—a fact that muddies the waters a bit. The ECMA Secretary General Jan van den Beld corroborated that IBM wants a Java standard. The reasons are clear: IBM is worried about Sun's dominance over the programming language and wants its Java investment protected. A standard would create a second source for the Java license and offer IBM the chance to drive the Java standard.

So, IBM and possibly Fujitsu, which vigorously support standardization with or without Sun, are on one side of the ECMA's TC41 committee. Hewlett-Packard (HP), Apple, and Compaq, which are against an effort to create an alternative standard, are on the other side of the committee and will likely withdraw from the TC41 committee.

Sun is between a rock and a hard place. In IBM, Sun has a Java partner with a vested interest in Java and that knows how to work with standards organizations. In Microsoft, Sun has a language competitor that has an interest in adapting Java for Windows, ignores standards organizations, and embraces, extends, and extinguishes competitors' products. Neither outcome (i.e, a standard outside of Sun's control or multiple Java implementations) would make developers happy. A third possibility exists: The final outcome might be an open-source model. Then, what group would be the keeper of Java? Stay tuned.