Click on our Sponsors to help Support SunWorld

The impact of Java standardization

Find out how Sun's approval as PAS submitter for Java really affects developers

By Bill Day
SunWorld
November  1997
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
Sun has received enough votes to become the official PAS submitter for Java ISO standardization. As the dust from the politicking begins to settle, what does standardization mean for Java developers? This article discusses the different parts of Java, which ones will be submitted for standardization first, and how both Sun and Microsoft will seek to use recent developments to their advantage. (1,950 words)


Mail this
article to
a friend
The road to standardization is a long and winding one. Languages can take years to reach approval in a standards body (C++ is only now receiving final approval), and often the specification of what originally goes in to the standardization pipeline differs dramatically from what comes out the other end. Getting a technology through standardization can at times seem to be a superhuman feat.

On the other hand, a great many licensees, markets, and business opportunities can never be realized unless their solution is built on a core of standardized technologies. Many government organizations contractually require software vendors to use standardized technologies. Many enterprises, likewise, prefer to invest in technology backed by a nice, thick standards document. Developers prefer to work with well-documented, widely supported technologies, and standardization helps to ensure both.

Given the stakes involved in the standardization of Java, it comes as no surprise that Sun (the major player seen to benefit from standardization of the entire Java platform) and Microsoft (the biggest player threatened by it), are both heavily engaged in posturing and rhetoric.

Ironically, both Sun and Microsoft seem to agree on one key element: Sun's approval as the Publicly Available Specification (PAS) submitter for Java helps to solidify Sun's central role in the development and specification of Java-based technology. (See Resources for links to Sun's press release and other related standardization information.) It's their perspective on what this means to their respective companies that differs. Sun wants to leverage every possible bit of this centrality to build support for its platform, and not coincidentally its business, while Microsoft wants to isolate the platform from the language and so protect its core business.

The rhetoric surrounding "Java platform versus Java language" has been applied so liberally that a lot of the underlying technical simplicity of what is at stake has been hidden beneath layers of marketing and spin control. This article aims to expose the simple technical details of what is proposed for standardization and how the process will likely unfold and affect Java developers.

Advertisements

What is this thing called "Java"?
The statement "We should standardize Java" is really quite vague. What exactly is it that should be standardized? If we buy into too much of either Sun's or Microsoft's rhetoric, we are in dangerous waters. As I see it, there are easily several potential standards:

Note: We could place another specification in this list, one for the Java bytecode. Bytecode is independent of the Java language (in fact, there are research compilers that turn code written in other languages into Java bytecode), but it is tied to the virtual machine. However, just as Intel MMX-ready processors can handle x86 and MMX instructions, it is theoretically possible to build a virtual machine that supports Java bytecodes and also some other bytecode. As the sole instruction set for all currently available commercial Java virtual machines, however, Java bytecode is, in practice, heavily tied to the VM specification. Because of this, I make no distinction between a potential Java bytecode specification and proposed virtual machine specification (and neither does Sun).

It is in Sun's best interest to ensure that all four of these separate (or orthogonal) parts are considered one interrelated technology. When Sun says "Java," it is referring to all four. Likewise, what Sun calls the "Java Platform" or "Java Application Environment" consists of a combination of the language, virtual machine, and APIs. As long as others agree with this definition of Java and the Java Platform, and are willing to cede approval to Sun as the Java PAS, Sun will maintain its guardianship over everything "Java." The approval of Sun as the PAS indicates, in part, the ISO's decision to give to Sun the authority to specify what is and what is not a part of the greater Java whole.

Note that the Java trademark itself is a major sticking point for Sun precisely because of the power it grants in relation to its Java strategy. Control of the trademark gives Sun the singular ability to lump all things under the umbrella of "Java." No wonder Sun has been so adamant about not relinquishing control of the trademark to the ISO. If it had done so, even for references only to the language and virtual machine specifications, any vendor could implement these two pieces, claim full Java standard compliance, and then build its own libraries on top, fragmenting the platform and undermining Sun's centrality. Thus, Sun's all-or-nothing strategy.

It is this very same Java whole that Microsoft is actively seeking to fracture. If the world were to recognize the language and virtual machine specifications as worthy of standardization, but the core and extension APIs as not, or if the Java trademark were applied to one or more parts of Sun's Java whole, but not to everything, Microsoft could rapidly fracture support for JavaSoft's Java Platform APIs. Such a tactic allows Microsoft to continue embracing the Java language while extending the Java Platform to its advantage. In fact, that is what Microsoft has been and is doing in spite of the ISO and standardization process.

Microsoft and Sun both realize that the key to the platform is not the language or virtual machine, but the core set of APIs. Thus, Sun's bundling of APIs with all other things "Java," and Microsoft's attempts to isolate APIs from these same others.

It behooves every developer to recognize the distinction and to understand both Sun's and Microsoft's game plans.

What will be standardized, and when?
Now that Sun has been approved as the Java PAS submitter, the company plans to submit the Java language, virtual machine, and some of the core APIs for standardization first. This process is not without precedent: The history of the C and C++ ISO standards illustrates a long, deliberate process of first standardizing language specifications and basic libraries before moving on to higher level functionality. Indeed, the C++ standard is only now being ratified, eight years after the original ANSI C standard was approved.

This is in keeping with Sun's philosophy and business objectives outlined above. If it sets the precedent of pushing the language, virtual machine and the APIs through the standards process, Microsoft's ability to isolate the Java Platform will rapidly diminish.

Expect Microsoft to resist Sun's approach with every fiber of its being. It has to resist. It has no choice. A standard Java Platform, with official ISO endorsement and support by hundreds or thousands of vendors around the world, is a warning shot across the Win32 API and Windows platform bow. We're not talking small-arms fire; these are a multi-targeted nuclear warheads! This is all out war.

So, what is best for developers?
In my opinion, JavaSoft's plans just so happen to mostly coincide with the best interests of developers and licensees. The language is mature and should be standardized as soon as Sun can submit the specification to the JTC1 for ratification. Similarly, virtual machine technology is fairly mature, as well. One might argue that it would be best to wait for some of the current JIT compilation and "adaptive optimization" technologies (used in JavaSoft's upcoming HotSpot virtual machine) to settle a little bit, but even allowing for these considerations, the virtual machine specification is almost ready for standardization.

The possibility of true portability is of critical importance to Java developers and relies on the language and virtual machine becoming open standards, run by the ISO and related bodies. Sun recognizes this fact and realizes that they do not stand to gain much by holding on too tightly to them in the coming months and years.

Unlike the language and virtual machine specifications, the Java APIs -- and even the core platform APIs (those standard APIs provided with the Java Development Kit and base Java runtimes by JavaSoft) -- are still in flux. The core platform 1.2 release, available only in early access review and without a publicly available implementation, will contain several new and important APIs. These include the much-hyped Java Foundation Classes, a mechanism for ascertaining which extension APIs are available in a given Java runtime, weak references, and more. It will likely take at least another year or two for the core platform and standard extension APIs to stabilize.

These APIs need to reach maturity before standardization can take place. For this to happen, Sun will need to retain control while focusing its efforts on the completion of these APIs. In addition, Sun needs to find a consistent way to support the use of standard and premium extension APIs, and a mechanism for migrating extension APIs into the Core Platform. This approach is necessary to build developer support for extensions and also to provide a standardizable process for dealing with extensions.

Conclusions
In so far as it staves off a fracture of the Java Platform APIs, Sun's control of the PAS submitter position for all things Java will benefit developers. Until the standards are settled, if someone asks you for your opinion on whether Java should be standardized, your first response should be "Which part?"


Click on our Sponsors to help Support SunWorld

Resources

About the author
Bill Day is a software engineer at Silicon Graphics Computer Systems. He worked on SGI's Cosmo Code Java IDE, created a test suite for the Cosmo Motion Java Media Framework implementation, and is currently the lead engineer on a SGI Java-based client-server project. In addition to writing for JavaWorld, Bill is authoring a book on Java Media for O'Reilly & Associates. When Bill is not writing or programming, he loves to travel with his wife, speak French, and enjoy life. Java, c'est magnifique! Reach Bill at bill.day@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-11-1997/swol-11-iso.commentary.html
Last modified: