How to avoid potential pitfalls of Microsoft's non-standard SDK for Java
Find out exactly which methods, classes, and variables have been added to, or omitted from, the key Java class libraries in
Microsoft's implementation of Java 1.1
Microsoft's Internet Explorer (IE) 4.0 has been out for a little over a week now, and the company now is shipping the 2.0
version of its Software Development Kit (SDK) for Java. According to Microsoft's Win32 Virtual Machine for Java Release Notes
(see the Resources
section below for links to this document and other information related to this article), the virtual machine (VM) for Java
that ships with IE 4.0 is the same as the one in the new SDK. Using the Java class files that come with the SDK and comparing
them to the Java class files that come with Sun's Java Development Kit (JDK) 1.1.4 release reveals exactly why Alan Baratz,
president of Sun's JavaSoft division, said, "Microsoft deceptively altered key classes and inserted them into their SDK."
(This was during the conference detailing Sun's October 7 announcement of Sun's suit against Microsoft alleging breach of
contract. For more information on this lawsuit, see "Sun-Microsoft dispute gets ugly
," in the October 1997 issue of JavaWorld
I have analyzed the classes and have run across seven areas that should be of great concern to developers if they want to develop solutions with Microsoft's SDK for Java that will work
in other Java 1.1 certified environments. These areas of concern are:
- new classes (Hey, what's that class doing there?)
- new methods (And where did these methods and instance variables come from?)
- new variables (And where did these methods and instance variables come from?)
- modified interfaces (What about the interface changes?)
- the com.ms packages (Inside com.ms)
- missing methods (What's missing in the SDK)
- behavioral differences (And what's different)
These go far beyond the often-cited concern over Microsoft's lack of JNI and RMI support, as mentioned in my October 1997
article, "What does Sun's lawsuit against Microsoft mean for Java developers?
Baratz used the word "deceptively" in Sun's announcement of the lawsuit because the (javadoc) documentation for the Java classes
that comes with the SDK makes no mention of these changes. To find these differences, it is necessary to use either the ClassVue
tool that comes with the SDK or manually examine the source code. Your best bet is to rely on ClassVue, as the source files
provided with the SDK are not always the ones used for the generated classes. For those unfamiliar with ClassVue, the equivalent
tool that comes with the JDK from Sun is javap, a class file internals examiner.
As much as I'd like to claim that what follows is an exhaustive list of changes to the SDK, it is possible that something
was missed. With several items, there is a pattern -- so if you avoid similarly named things you should be okay. All of the
problems identified here are in the java.lang, java.io, java.awt, java.util, and java.security packages/sub-packages.
So, what changed in each package?
- java.awt: New classes, New methods, New variables
- java.lang: New methods, New variables
- java.io: Dropped methods
- java.security: Modified interfaces
- java.util: New methods, New variables
The first set of changes in Microsoft's SDK for Java is new classes, methods, and variables that were added to the system
packages. A system package, or core Java API, is anything that begins with java.* in its fully qualified class name. So, as
far as new classes go, 16 new ones were added into java.awt. These are: