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

1 2 Page 2
Page 2 of 2

For the more technically inclined readers, here are some details on even more changes. Other behavioral differences, some of them improvements, are invisible to developers. For example, object locking may be done at different levels, sometimes favoring one environment over the other. Hopefully, any improvements made by Microsoft will make their way back into the JDK and vice versa. There are additional performance benefits within Microsoft's environment that should be incorporated into the JDK. For example, in Microsoft's environment, if you ask to change a component color or font, it checks to see if the new value is different from the old value. If they are the same, no change is made. With Sun's environment, the change is blindly made, even when unnecessary. Lots of little modifications like these can lead to dramatic performance improvements.


It seems without question that Microsoft (and Netscape -- see the sidebar below) has made changes to key Java class libraries. Whether or not Microsoft legally can, based on a contract with Sun, is now in the court's hands. While, as a whole, the changes appear relatively minor, they are changes. If the courts say these alterations are okay because they are insignificant, what is there to stop a licensee from altering other capabilities?

Let's take a quick look at the different changes, and see where they leave developers and users:

  • Missing RMI and JNI support: If programs need these capabilities, they will be missed. Developers will need to deliver programs with Sun's Java Runtime Environment (JRE) to ensure a compatible environment. Hopefully, users shouldn't notice, although some programs, which would function better when run as an applet within a browser, may need to be converted into a standalone application.

  • Added classes, methods, and variables: For developing 100% Pure Java solutions, developers will need to avoid them. While the task is generally easy, there is no tag similar to @deprecated warning developers when they slip and use a non-portable feature. If developers aren't careful, users will notice when programs stop running or never start if run outside of a Microsoft Win32 Virtual Machine.

  • Added methods to interfaces: Along with the next point, this is probably one of the biggest faults. If you currently have classes that implement the modified interfaces, the likelihood of them working in Microsoft's environment are slim. You would have had to introduce methods identically named with identical functionality in order for the classes to work. Now, in order to create solutions that work in both Microsoft and non-Microsoft environments, developers need to define methods with the names and behavior introduced by Microsoft's extended interfaces. Until then, any prior working solutions that utilized these interfaces will not work on a Microsoft Win32 Virtual Machine.

  • Missing ByteArrayOutputStream method: While this missing method appears relatively minor, it is probably one of the biggest faults. A 100% Pure Java program that runs perfectly well within Netscape Navigator/Communicator or with the JDK/JRE just won't work in Microsoft's environment. Yes, developers can work around the missing method easily, unless something indirectly uses the method. For any product that has already shipped, however, this could force endless wasted technical support hours, with the possible need to update product and reship to support Microsoft's incompatible environment.

  • Using classes: While Microsoft seems to be ignoring the standard package-naming conventions (rather than employing the reverse-domain-name nomenclature, Microsoft uses "," which is the domain of Morgan Stanley), this type of enhancement is encouraged. While using most of these capabilities locks you into Microsoft's environment, it is a choice developers can clearly make. Unlike the previously mentioned modifications, a developer cannot accidentally access something that isn't portable. As long as Microsoft-specific Java programs are properly flagged, users should have no problems. This does bring up the possibility of a program similar to the 100% Pure Java initiative for those programs that are Microsoft-specific.

  • Regarding behavior differences: Unfortunately, these things happen. Living to the letter of the Application Programming Interface (API) permits behavior differences based upon implementations. While some of the differences seem to be Microsoft's attempts to reduce the number of incompatible changes in the 1.1 AWT, other changes are not. There are also welcome performance improvements. While some of these differences may prove to be annoying for both developers and users, if a developer is relying on a specific implementation that is a problem, Microsoft should be thanked for fleshing this out now.


The Java world is unfortunately diverging. With the first beta-release of Java 1.2 imminent, and Microsoft promising not to support pieces of that, visions of IBM vs. Apple (PC vs. Mac) are becoming more commonplace. Developers only want to get a job done, while Microsoft and Sun argue over what's in the Java toolbox. Who eventually wins in court, only time will tell. Until then, developers need to understand the disputed technologies and make informed decisions. Until the contentious companies are together again, users and developers are caught in the middle of a closing vice with some tough decisions to make. While most of the differences between platforms are minimal, they are there. So, do you abandon Java's "write once, run anywhere" philosophy and use Microsoft's VM-specific extensions, or do you make a commitment to Sun's 100% Pure Java philosophy? If your task doesn't require JNI and RMI, it isn't an easy choice.

Thankfully, with Microsoft's SDK you can still create 100% Pure Java solutions. By avoiding the new classes, methods, and variables injected into the key Java class libraries and the non-portable packages, you can create cross-platform Java programs. By working around the added/missing behavior, you also can create programs that will work within IE 4.0 from certified Java 1.1 tools like Sun's JDK, JBuilder, VisualAge for Java, or Visual Cafe 2.0. Good luck.

john.zukowski 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

  • Sun Microsystems, Inc. v. Microsoft Corp.
  • "Sun-Microsoft dispute gets ugly," JavaWorld, October 1997
  • "What does Sun's lawsuit against Microsoft mean for Java developers?", JavaWorld, October 1997
  • Microsoft's Win32 Virtual Machine for Java Release Notes
  • Rule 3 of SunTest's "100% Pure Java Cookbook"
  • Microsoft's Application Foundation Classes
  • Internet Explorer 4.0
  • Microsoft's SDK for Java
  • Microsoft does provide RMI (along with other unsupported tools, utilities, and libraries) -- via an FTP server
  • Borland's JBuilder
  • IBM's VisualAge for Java
  • Symantec's Visual Cafe
  • Should Microsoft be allowed to alter the key class libraries of Java? Take our latest poll
  • A review of platform-neutral Java development tools in NC World, JavaWorld's sister publication
  • Nick Petreley's commentary about the Sun/MS lawsuit, also in NC World
  • Alex Chaffee's analysis of Java implementation differences
1 2 Page 2
Page 2 of 2