What does Sun's lawsuit against Microsoft mean for Java developers?

Find out how Microsoft's release of IE 4.0 and SDK for Java may affect you!

October 7, 1997 -- Sun has responded to Microsoft's 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, Microsoft made the choice last week to ship products it claims are fully Java 1.1 compliant, but which failed to pass the Java 1.1 compatibility tests the company received from Sun in February. "Microsoft embarked on a deliberate course of conduct to fragment Java," said Alan Baratz, president of JavaSoft, during a Sun teleconference today at 10:30 a.m. PST.

From a developer's perspective, what does this mean? Well, first, 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. Specifically, 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.

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 RNI, 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 RNI 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), depending on the background of the person speaking. 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 is geared toward the Microsoft world, only recently becoming available for the Unix world with products like EntireX from Software AG. 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, since 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.io packages, as Microsoft did, is extremely problematic. "Microsoft deceptively altered key classes and inserted them into their SDK," said Baratz, which results in developers thinking 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 work only 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 incompatible elements 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.

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.

Learn more about this topic

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more