The Sun-Microsoft lawsuit: A developer's perspective

How does Microsoft's release of IE 4.0 and SDK for Java affect you?

By John Zukowski
SunWorld
October  1997
[Next story]
[Table of Contents]
[Search]
Sun's Site

Mail this
article to
a friend
October 7, 1997 -- Sun responded today to Microsoft's recent release of Internet Explorer (IE) 4.0 and its 2.0 release of the SDK for Java (SDKJ) with a lawsuit in U.S. District Court. According to Sun's press release, "the complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract."

Specifically, Sun says Redmond chose last week to ship products it claims are fully Java 1.1 compliant, but which failed to pass the Java 1.1 compatibility tests -- tests the company received from Sun last February. "Microsoft embarked on a deliberate course of conduct to fragment Java," says Alan Baratz, president of JavaSoft.

What does this mean to developers? Well, Microsoft does not support the Java Native Interfaces (JNI) or the Remote Method Invocation (RMI), and it has altered the Core Java class libraries with about 50 methods and 50 fields that are not part of the public Java Application Programming Interfaces (APIs) published by Sun. So if you create something with Sun's 1.1 JDK (or with the Java 1.1-certified environment from another company, such as IBM, Borland, and Symantec), it may not run under IE 4.0. Also, if you create something with Microsoft's development environment, it may not run under a non-Microsoft Java 1.1 environment.

Advertisements

JNI and RMI: Why Microsoft's rejection of these poses a problem
JNI is the native code interface used to access platform-specific capabilities like a serial port or a microphone -- for things that aren't available yet through the core API. The goal of JNI is to permit developers to provide a single set of native libraries for every Java implementation on a specific platform.

Microsoft has decided to support its own interface, called RMI, which provides the same capabilities as JNI. By not supporting JNI, Microsoft is forcing developers to provide different libraries for Microsoft and non-Microsoft Java virtual machine (JVM) users. There is nothing wrong with Microsoft's support of RMI if the company thinks its technology is better. However, by not supporting JNI, Microsoft cannot claim IE 4.0 is fully Java 1.1 compliant.

RMI provides a means of executing Java code on foreign Java virtual machines. It is frequently compared to Remote Procedure Calls (RPC), Common Object Request Broker Architecture (CORBA), and Distributed Component Object Model (DCOM). Microsoft claims it supports DCOM instead of RMI because RMI doesn't support Java-to-non-Java communications. The specific purpose for using RMI is for Java-to-Java system communications. For example, with RMI, you can invoke methods of objects existing in other Java virtual machines, without knowing the class type, while preserving Java's runtime safety.

If you need to move outside Java-to-Java communications, CORBA actually is the portable solution, not DCOM. Why? DCOM locks you into the Microsoft world and is just not an option in the Unix world. If you need to use RMI, obviously Internet Explorer is not an available option. If you need Java-to-non-Java system communications, to interface with legacy (non-Java) systems that rely on CORBA, Netscape Communicator 4.0 ships with Visigenic's VisiBroker ORB. (For RMI support with Netscape Communicator, you need to use a beta release of a browser patch because Communicator does not claim to be a Java 1.1 browser.)

Rotten to the Core Java API: The crux of the problem
The last Java 1.1 incompatibility problem identified is actually the scariest. It is easy to avoid RMI and JNI if your application permits it: You just don't use them. The sticking point is that Microsoft decided the Core Java class libraries were insufficient for its needs. Now there's nothing wrong with extending things by subclassing and placing the new objects in a package outside of the java.* class hierarchy. But deciding to add about 50 methods and 50 fields into the classes within the java.awt, java.lang, and java.net packages, as Microsoft did, is extremely problematic. "Microsoft deceptively altered key classes and inserted them into their SDK," says Baratz. This means developers might think they are writing Java, when actually they are writing something that runs only on Internet Explorer.

How do Microsoft's additions to the classes affect Java developers? Well, if you rely on these changes, or just inadvertently use them, your program will only work within Microsoft's Java system. Also, if you create a program outside of Microsoft's development environment, it will expect a certain core API. Unfortunately, that Core API is different from the one within Microsoft's environment, so the program may not work there. The compatibility suite test that flagged this problem is what's called a signature test.

As an example, if method foo() is supposed to accept a parameter of type bar, it better get an object of type bar. If someone wants you to pass in an object of type baz instead, it will work only on those systems that changed the core to accept it. And Microsoft introduced that change. Now, Microsoft may think it stands as the reference implementation of Java for Windows. But the fact is, only Sun can introduce changes to the Core Java API. Yes, any licensee can ask for changes, and many frequently do. But Microsoft single-handedly, and without permission, decided to change these things.

In the end, the goal of the lawsuit is, in Baratz's words, "to get Microsoft back into compliance," and as quickly as possible. But until the legalities are resolved, Sun will withhold from Microsoft all ongoing Java technology improvements, such as the new Java 2.0 virtual machine called HotSpot. If Microsoft doesn't come back into compliance with Java, it will need to come up with a clean-room implementation of its version of something that won't be called Java -- that is, if it wants to do something with the equivalent of Java bytecodes. Who knows what will happen to IE 4.0, the SDK for Java 2.0, and the next Visual J++?

Words of wisdom: Let the Java developer beware
As a developer, you'll have to tread very carefully. If you decide to use Microsoft's development environments and need to create cross-platform solutions, be very familiar with the Core Java APIs. You will have to avoid anything that isn't part of the public specifications. Until a complete list of what is incompatible is published, the onus will be on individual developers to know what is and isn't compatible. Of course, if you don't care about "write-once, run anywhere," you can use Microsoft's platform-specific capabilities. It is possible, however, that Microsoft's Java license will be revoked. Sun already is attempting to revoke Microsoft's ability to display the Java-compatible logo.

About the author
John Zukowski is a Software Mage with MageLang Institute, author of Java AWT Reference from O'Reilly & Associates and Borland's JBuilder: No experience required from Sybex, as well as the Focus on Java guide at the Mining Company. Reach John at john.zukowski@sunworld.com.

Resources

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]
Sun's Site 		[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-10-1997/swol-10-lawsuit.html
Last modified: