Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

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

The current state of affairs with regard to Microsoft's Java environments is changing again.

Microsoft recently released two new versions of its command-line SDK for Java environments: version 2.02, an upgrade from its 2.01 release, and 3.0, a pre-release version. (At the time of publication, Microsoft had not yet revealed the date the full releases will be available.) In addition, Microsoft's oft-maligned Visual J++ (VJ++) 6.0 is newly available in its second beta release (available for general release around mid-September), and the runtime environment for the company's Internet Explorer (IE) Web browser includes a new service pack (SP1) that users can add on to the 4.01 release. (SP1 gives IE4 access to the new Windows Foundation Classes library, first introduced with VJ++ 6.0.)

With all these changes, Sun's Carla Schroer, senior engineering manager of the Java Compatibility Suite, is taking another look at just how compatible Microsoft's latest implementation is and she isn't being shy about telling people what she's found. And, in the spirit of providing an updated Pitfalls article, we're telling it as it is, too.

Schroer reports that the compatibility of Microsoft's Java releases is a "moving target. With each new product, there are differences." And these differences need to be analyzed to be understood. This latest release, the 3.0 pre-release, includes a cleaned-up version of the mislabeled class libraries that Sun previously complained about. The good news: the public AWT peer classes in the java.awt package as well as the added public methods and instance variables have been removed. The bad news: if you created any Java programs that used these capabilities, they'll no longer work. More good news: you will no longer be able to create programs that access non-standard classes, methods, and variables within the java.* packages.

Although the cleaned-up Core API is a good thing, Schroer feels the remaining incompatibilities -- the lack of JNI and complete RMI support, as well as added keywords and compiler directives -- are still important.

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. Although once you decide to use JNI, you lock your Java program to the platforms in which you provide native libraries, the lack of JNI support in Microsoft products requires native-library vendors to maintain multiple libraries for integration into different Java virtual machines on the same platform.

When it comes to RMI, the remote method invocation library for executing Java code directly within other Java virtual machines, Schroer reports that while Microsoft has provided the RMI classes separately from all its products, it doesn't provide the rmic compiler. According to Schroer, the Technology License and Distribution Agreement requires Microsoft, where it provides a development environment, to deliver one that is complete. The lack of the rmic compiler makes both the SDK and J++ environments incomplete and, thus, incompatible and in violation of the agreement. Bill Dunlap, the Visual J++ product manager at Microsoft, disagrees with this assessment.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.