Microsoft sheds its Java skin -- again

Another series of changes to Microsoft's Java implementation has Sun officials hot on the trail of incompatibilities

By John Zukowski, JavaWorld.com, 08/01/98

Page 2 of 2

Finally, says Schroer, the added keywords and compiler directives create Java source code that is not compiler and runtime-environment independent. This means that Microsoft's additions "do not just create a runtime tie, but a development environment tie, too." If you use them, you must forever use Microsoft's development tools and runtime environment. While support from Microsoft for the added keywords (multicast and delegate) is specific to Microsoft's Java VM, nothing in the implementation is specific to Microsoft's VM. Someone could reimplement the functionality using Java's reflection capabilities for other JVMs. While this approach would be slower than Microsoft's native library implementation, it would work.

The compiler directives issue seems to be more of a true compatibility problem; non-descriptive attributes are placed in class files that only Microsoft's Java VM understands. By compiler directives, I am referring to the @ddl commands in javadoc-style comments, like these:

/** @dll.structmap([type=FIXEDARRAY, size=2]) */
/** @dll.struct(pack=1, auto) */
/** @dll.import("GDI32",auto,setLastError) */
/** @dll.import("KERNEL32",auto,entrypoint="GetLargestConsoleWindowSize") */

According to Schroer, adding attributes to class files is perfectly legal, as long as they're only descriptive. However, adding functionality behind those attributes is in violation. As an example, Schroer described the @dll.import directive. When the Microsoft compiler finds this directive in the source, it adds an attribute to the class file to load the specified dynamic library. However, the standard Java way to load a library is with the System.loadLibrary() method. Because non-Microsoft Java VMs will not recognize the attribute added by the @dll.import directive, the necessary library will not load and the program will not work correctly. Hence the claim of incompatibility.

Schroer is quick to point out that these claims result in "no lawsuit change." It's just that there are "different incompatibilities with each product" release. Which, I'm sure, makes compatibility testing very difficult.

And how does Microsoft feel about this? According to the whitepaper Microsoft's Java Strategy: Helping Java Developers Succeed (April 1997), "Microsoft's Java strategy calls for it to deliver both the power for real, cross-platform applications and the choice to create great Windows-based applications using Java that take full advantage of customers' hardware and software investments."

While these latest changes let developers better create cross-platform solutions (now that the Core Java APIs are back to Sun's defined Core), a later statement in the whitepaper seems to be at jeopardy: "To do this, Microsoft remains committed to best-of-breed Java support that's fully compatible with existing Java tools and code." Fully compatible? I don't think so. The added keywords and compiler directives are clearly not fully compatible with existing tools and code.

Welcome to the world of proprietary Java.

About the author