Sponsored Link •
Artima.com columnist Frank Sommers interviews Rob Gingell, Sun Microsystems' fellow and chief engineer and chair of the Java Community Process, about the pressures on vendors to both create froth—to add value on top of standards—and maintain compatibility in a multi-vendor industry.
When you write a piece of Java code, you know that code will run on a variety of machines: Windows, Linux, the MacOS, the Palm, and so forth. Platform-to-platform Java portability works because the Java Virtual Machine (JVM), the Java byte codes, and your program's APIs all adhere to strict specifications.
However, what if those specifications, and their implementations, were developed in an open source manner? Would Java still preserve its remarkable platform independence? Or would it be fragmented into myriad incompatible versions and implementations? How could you be sure your servlet or MIDlet will work when executed on a different JVM and OS?
These are just some of the questions the Java Community Process (JCP) recently examined. The JCP, the primary forum for Java's advancement, in theory is an open process: Anyone paying a small membership fee can participate. In practice, it has been branded as a politically charged club of large corporations, with Sun at the helm, all vying for a piece of the Java pie. Due to its restrictive licensing model, the open source community has completely shunned the JCP.
In response to those charges, and for fear of missing out on the open source action, the JCP adopted a new set of rules in November 2002. The most important of those rules explicitly allows JCP members to develop new Java standards in an open source manner, while still under the JCP's umbrella and official blessing.
Frank Sommers asked Sun Microsystems fellow and chief engineer Rob Gingell, who also chairs the JCP, about the impact of those changes. In this interview, which is being published in two installments, Gingell tells us what causes fragmentation in a marketplace, and how Java can avoid that danger:
Frank Sommers: The Solaris application binary interface (ABI) has served to ensure compatibility between Solaris and its applications. Will the Java binary format and JVM assume similar roles in Sun's future? In other words, will Java be Sun's universal ABI?
Rob Gingell: Yes, the primary ABI of our future lies in IP/JVM (Internet Protocol/Java Virtual Machine). The JVM serves as the instruction set architecture. A collection of IP-based protocols serves the role we formerly ascribed to operating systems. That is a softer definition than what we used during most of the 1990's—namely Solaris/SPARC. That doesn't deny Solaris/SPARC, Unix, or microprocessor development in general, but it does recognize the growth of a new class of applications, enabled by the network's ubiquity. Those applications add to our existing business in a powerful way.