Follow-up: “How to avoid potential pitfalls of Microsoft’s non-standard SDK for Java”

Last month’s article “How to avoid potential pitfalls of Microsoft’s non-standard SDK for Java” inspired a considerable amount of reader feedback. As a result of some of the reader comments, I thought I would write a short follow-up article to help clarify a few important points. There are five points that I feel need clarification:

1. Microsoft’s Application Foundation Classes (AFC)
2. Locale changes
3. Remote Method Invocation (RMI)
4. Behavioral differences
5. Netscape’s Java patch for Communicator

Note: The reader feedback on this article can be found at ‘Pitfalls’ article receives attention from JavaWorld readers.”

Microsoft’s AFC

In my initial article, I stated that using the Application Foundation Classes (AFC) packaged with Internet Explorer 4.0 (IE4) and the Microsoft Software Development Kit (SDK) for Java version 2.0 should permit developers to create Java solutions for non-Microsoft Java environments. The only condition was that Microsoft had to package AFC to be usable outside of Microsoft’s Java virtual machine. Since the article was written, Microsoft has stated that it will not be shipping a pure Java version of the AFC classes that includes IE4 anytime soon. It will, however, ship a pure Java version of AFC for Java 1.0.2 environments. Once this ships, developers will be able to create cross-browser solutions with AFC. However, the Application Programming Interface (API) of the two releases will be different, as the version shipping with IE4 and the SDK supports the Java 1.1 event model, as well as the 1.0 event model. I suspect it will be possible to create solutions that work with both versions of AFC, just like Java 1.0 applets work within Java 1.1 environments. However, this won’t be clear until the release of the AFC version for Java 1.0.2.

Also, since the article was written, Microsoft has released a preview version of IE4 for Macintosh and Solaris platforms. According to Charles Fitzgerald at Microsoft, the AFC that comes with these two releases is compatible with the IE4-for-Windows releases. Assuming the AFC releases are compatible, this would permit cross-operating system platform AFC solutions, but not cross-Java virtual machine solutions. (HP-UX and AIX versions of IE4 should be available soon.)

Here’s another piece of information worth mentioning: As the AFC classes are not “serializable” out of the box, they are not directly usable as JavaBeans components with beans-compliant tools. They are still usable at the source level, and can be rendered serializable, but Microsoft has chosen not to make the AFC components beans yet.

Locale changes

In the earlier article, the addition of about 50 public instance variables to the Locale class was mentioned, along with additional support files in the java.text.resource package. While the Locale instance variables are specific to Microsoft’s class libraries, the existence of supporting Java classes for the Locale objects is not specific to Microsoft’s environment. What this means is that you can still use the date and text formatting support classes for the various Locales. However, you shouldn’t use the Microsoft-specific constants. So, for example, instead of using the Microsoft-only constant Locale.FINNISH, you should create a new Locale object with new Locale ("fi", "FI") or new Locale ("fi", "").

RMI

In case you missed the Resources link in the previous article, Microsoft offers Sun’s RMI classes for use with its Java virtual machine. This was apparently made available in August but was rather difficult to locate unless you knew to search for rmi.zip. It is now listed with other Java resources available from Microsoft (see Resources). While Microsoft doesn’t provide any support, in order to use the classes with IE4, they must be installed locally. An applet that wants to use RMI cannot download the RMI classes over the Internet. In other words, the RMI classes must come from a trusted source (be loaded locally).

Behavioral differences

Various readers pointed out additional behavioral differences of the Microsoft Java implementation, and even created Web sites to demonstrate these issues. As I primarily looked at the API differences in the first article, I was not surprised to find that people were encountering additional problems when using the Microsoft Java classes more heavily. As developers, we need to be aware of these things and program around them whenever possible. Microsoft has stated that some differences have been logged as bugs and have been corrected. Until the corrected JVM propagates out, it’s good to know about these problems so as not to go crazy trying to figure out what is wrong.

Untrusted applets and displaying menus in frames

The first problem pointed out by a reader has to do with displaying menus in frames, opened from untrusted applets. The error is demonstrated at https://www.sc-systems.com/public/misc/IE4MenuBug/. An untrusted applet’s warning message seems to take up the space the frame needs to display the MenuBar in IE4, whereas it appears correctly in Netscape browsers and in Internet Explorer 3.0. While the test case does demonstrate a particular way in which IE4 can fail, the means used to display and size the frame are not normal. Most people will not run across this particular problem using setSize() and setVisible() to show a frame. On the other hand, developers who frequently call addNotify(), setSize(), and then setVisible() will have problems. One should never need to call addNotify() directly to create a component’s peer. If a program requires information that only a peer can provide, override the addNotify() method, have the new method call super.addNotify() first, then use the now-available information in the overridden method.

Using IE and the SOCKS proxy server

The second problem that a reader identified has to do with Internet Explorer being configured to use a SOCKS proxy server. If IE is configured to use a SOCKS proxy server, then Java applications started from “jview” (the SDK’s command-line loader for Java) use the proxy server. If the local firewall has no knowledge of the internal network configuration, then when the SOCKS server is queried for the address of a local host, it performs the query against the general Internet namespace and fails. Apparently, Microsoft’s implementation of the abstract SocketImpl class, with the package private PlainSocketImpl class, looks in the Windows registry and then uses the proxy host for hostname resolution. Upon failure, a plain socket access throws a SocketException with Microsoft’s virtual machine, but works correctly with the JDK and Netscape environments. For a more complete description of this problem, see https://www.findmail.com/listsaver/advanced-java/4873.html, which has the best information.

There is a workaround for this problem, but keep in mind that this problem is not new to Microsoft’s latest IE4 or SDK for Java release. Sundar Narasimhan of Ascent Technology, a distributed software solution provider, provides the following workaround: Turn off the use of the SOCKS proxy by removing the “socksProxyHost” System property with the following code:

Properties p = System.getProperties();
if (System.getProperty("java.vendor").equals("Microsoft Corp.")) {
  p.remove("socksProxyHost");
}

Compiler differences: Sun’s javac and Microsoft’s jvc

The third problem we’ve come across has to do with different behaviors between the javac JDK compiler and the jvc SDK compiler. When an inner class accesses the private variable of an outer class, Sun’s Java compiler handles it differently from Microsoft’s compiler. The differences are documented in “Inner Class Access to Private Members of Enclosing Class” (see Resources). It seems that when creating cross-Java system solutions, one shouldn’t access private variables of outer classes from inner classes. Instead, one should either create accessor routines for the variable, or change it to package private. Other compiler differences you should be aware of are specified on the same “Inner Class Access…” document.

Other problems found:

• Toolkit.beep() is not permitted from untrusted applets
• List.setForeground() / setBackground() is ignored

Netscape problems

In the Netscape sidebar, I mentioned the changes Netscape has made to its Java libraries with the Communicator patch — and the problems these changes can cause. According to a WebWeek article by David F. Carr (see Resources), Sun is aware of these problems, and Netscape has signed a written agreement promising to correct them before the final release. Until then, if you do use Netscape’s Visual JavaScript tool (also currently in beta release) to create solutions using JavaBeans, you have access to the non-standard Java extensions from JavaScript. This means the Visual JavaScript tool can create programs that will not work outside of Communicator. As with the Microsoft-specific extensions, avoid Netscape-specific extensions until the problems are corrected.

Conclusion

My conclusions after looking further at Microsoft’s SDK for Java and IE4 aren’t new. If you want to create cross-Java implementation solutions, the job has gotten more difficult with Microsoft’s latest release. AFC isn’t a cross-implementation option yet, and it won’t be for some time if you want to use it in a JavaBeans world. An AFC release for Java 1.0.2 is imminent though. Also, the Locale constant additions aren’t as troublesome as initially suggested, and the RMI classes are available from Microsoft, for use within its environment.

And yes, there are behavior differences and bugs in Microsoft’s Java implementation. One would have hoped that more of the problems and differences could have been worked out before a release, but there is talk of a 1.1.6 release from Sun already. So, it has taken Sun some time to get things right, too. Since the initial problems were encountered, it appears Microsoft has become more responsive to developers’ concerns and problems with the implementation. As with JavaSoft, Microsoft has made available pay support options; see Resources for the link to this help page. (If the problem turns out to be a bug, the support cost is not charged.) Finally, it’s worth noting that an updated Java environment was released by Microsoft at the end of October that fixes the Menu and Toolkit.beep() bugs mentioned above. This version also adds the missing ByteArrayOutputStream method that was left out of the initial release. Stop by and download the new version if you’re still encountering these problems.

Source: www.infoworld.com