Sun to open Java processes to nonlicensees

November 9, 1998 — In response to some disgruntled elements within the Java community, Sun Microsystems in coming weeks will announce a new process that allows non-Java licensees to have a role in defining new Java APIs across the spectrum of Java classes.

“We’re making it possible for anyone who wants to be involved in early development to get in. They just need to sign a participation agreement that they will work in Java’s best interests, and pay an annual fee,” said Jim Mitchell, vice president of architecture and technology at Sun, in Cupertino, CA.

The process could start by December, and annual fees should be no more than ,000, with discounts for nonprofit organizations, Mitchell added.

Sun’s broadening of the process behind the standardization of Java APIs and classes comes as a group of embedded systems developers have splintered from Sun over Java issues. (See Resources for a link to a related story.)

While Sun is opening the creation process on a range of specifications, it’s also keeping tight control over the definition of the Java programming language and the emergence of various Java virtual machines (JVMs).

The new process will prevent parties from bringing patented technology into the Java milieu, so as to block the possibility of an avalanche of royalty payments that would stymie Java’s use, Mitchell said.

The move to open Java comes amid several budding initiatives designed to hold the Java movement together, placate fractious partners, and prevent segmentation of Java, while easing the ability to deliver write-once, run-anywhere functionality.

Among the new initiatives, in coming weeks Sun will redefine how licensed partners create and test JVMs, Mitchell said. “There will be more opening around JVM implementations,” he commented.

Sun will also announce the Java Platform for the Enterprise (JPE), which consists of reference implementations such as Enterprise JavaBeans (EJB), compatibility testing, and programming guidelines for building around Java, said Jon Kannegaard, Sun’s vice president and general manager of Java platforms.

JPE forms a collection of the dozen or so existing APIs, such as EJB, that form the enterprise computing infrastructure around Java, Mitchell added.

All in all, Sun is making Java more open — but not an open-source code technology, as with Linux, the Apache server efforts, and the browser-oriented Mozilla.org process.

In effect, Sun is playing “benevolent dictator” by maintaining the last say in defining what is and isn’t Java, but that may be the only way to create standards that work together, said Eric Brown, an analyst at Forrester Research, in Cambridge, MA.

“This is such an important issue,” Brown said. “There is something unique about Sun’s approach in that it’s not completely open … but to exclude nonlicensees from the decision making or advisory process taints the whole idea of industry standards.”

The bottom line, Brown said, is that Sun needs to be trusted to keep a “church-and-state” separation between its Java stewardship and its product development.

“State can make a ton of money on Java, but not church,” Brown said. “Java purity is in the heart as well as the mind for these people at Sun.”

Separately, Sun, in further defining the EJB specification, plans to deliver a fix release to EJB 1.0 in either January or February, according to vendors briefed by Sun. It will add reference materials for code snippet compiles, Extensible Markup Language support for the data finder, and other improvements, the sources said. It will be followed by EJB 1.1 in April or May, and EJB 2.0 by the end of 1999, they said.