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
I have analyzed the source files and have run across six issues 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 six concerns are: new classes, methods, and variables; the com.ms packages; missing methods; and behavioral differences. They go far beyond the often-cited concern over Microsoft's lack of JNI and RMI support, as mentioned in my other JavaWorld article this month, "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.
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, and java.awt packages/sub-packages.
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. As for classes, 16 new ones were added into java.awt. These are:
With the exception of the last one, all of the classes above are peer classes for AWT components. Normally, these classes
would go into a package like sun.awt.windows or sun.awt.motif. Since you aren't supposed to use them anyway, they should be
easy to avoid. The
WUIPeer class also is a peer, but it supports a Microsoft-specific behavior. Stay away from that too. Additional package private
(also called friendly, for when no access specifier keyword is specified) classes were added, like
__UIMenuRoot. Because these are inaccessible outside of java.awt, you cannot directly use them.