Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Sun vs. Microsoft, Round 1

The battle for control of the Java language and its surrounding technology gets underway with a bang of the gavel

By Eric Armstrong, JavaWorld.com, 10/01/98

Page 3 of 7

At the end of the day, the contention that JNI was subsumed under the definition of the AAPI did not seem to be seriously challenged by Microsoft's attorneys. They attacked it in a number of ways, however. The remainder of this article examines the validity of those arguments.

Contractual obligation?

Because JNI did not exist at the time the Java licensing contract was signed, Microsoft contends that it was under no obligation to support it. Since it is not part of the Java Language Specfication, and not part of the Java virtual machine (JVM) Specification, it does not exist as a contractual entity. On the other hand, the Remote Method Invocation was part of the original JVM specification, and JNI is its successor.

The contract between Sun and Microsoft (which you can find online; see Resources) says that Microsoft is required to pass compatibility tests for the "technology" and for its upgrades, which is defined to include the Applet Application Programming Interface (AAPI). The AAPI, in turn, is defined as including the "OEM Java Virtual Machine Specification ... [and the] OEM Java API Specification, as modified by Sun during the term of [the] agreement" (emphasis added). So if either the AAPI or the OEM Java API Specification includes JNI, it would certainly appear that Microsoft is obligated to support JNI.

During the proceedings, Microsoft repeatedly claimed that JNI was nowhere mentioned in the contract's appended "Exhibit A", which is a description of the technology and the documentation. On the other hand, that exhibit does include the Java Runtime Interpreter under the description of the technology, and it includes both the OEM Java Virtual Machine Specification and the OEM Java API Specification in the list of associated documentation. And Sun contends that JNI is an enhancement of the RMI that was part of the original specification. So the odds are good that Sun is on safe ground, even if JNI is not specifically mentioned in the original version of the JVM Specification. But once again, this is the law. The outcome hangs on a definition.

Platform-independent specifications versus platform dependencies

Microsoft argued that the Applet Application Programming Interfaces cover machine-independent interfaces. Since native code is machine-dependent (so the argument went), JNI is not covered by the AAPI. Now, at best, this argument is spurious. (Spurious: seemingly meaningful, but in fact groundless.) At its worst, it is intentionally misleading. The fact is that JNI is a machine-independent interface. That is its beauty. Writing to this specification, a Java developer can use the Java virtual machine to link to a small machine-dependent module written either by himself or others.

Using JNI, it becomes possible for a company that produces a scanner, for example, to write a small machine-specific module for each system the scanner can be connected to. The scanner purchaser can then install the module that is appropriate for his platform. Any third-party Java program written for that scanner will then run, regardless of the platform it happens to be connected to. Such is the beneficial effect of standards.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.