Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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.