本文提供更多的技巧，使读者能了解怎样绕开Microsoft的JavaSDK中的错误(以及Netscape的Communicator补丁中存在的问题)
[摘要]在“如何避免Microsoft非标准JavaSDK的潜在危险”这篇文章刊出之后，读者的反馈信息蜂涌而至，其中不少读者指出了Microsoft的Java开发工具中存在的另外一些潜在问题。本文将围绕着自前一篇文章刊出之后，读者提出的五个具体问题展开讨论，提供更多的补充。
上个月刊出的文章“如何避免Microsoft非标准JavaSDK的潜在危险”，引来了数量相当可观的读者反馈。针对某些读者的评论，我认为有必要写一篇后继短文来帮助我们澄清几个观点。以下五个方面，是我认为需要加以说明的：
1.Microsoft的应用程序基本类(AFC)
2.Locale的变化
3.远程方法调用(RMI)
4.动作差别
5.NetscapeCommunicator的Java补丁。
Microsoft的AFC
在前面的文章中，我曾声明过，将应用程序基本类(AFC)与InternetEXPlorer4.0(IE4)和Microsoft的java软件开发套件(SDK)第二版包装在一起，应当使开发者能够开发出独立于MicrosoftJava环境的Java解决方案。对于这一点，所需要的唯一条件就是Microsoft必须将AFC的利用范围限制于Microsoft的Java虚拟机之外。在该文写出之后，Microsoft曾声称，就目前而言，在短期内，它将不会装备一个包括IE4的、纯Java版本的AFC。然而，它将会为Java1.0.2环境装备一个纯Java版本的AFC。一旦这种装备完成了，开发者就将会通过AFC，创建交叉浏览器解决方案。值得注重的是，这两个版本的应用程序开发接口(API)将不会相同，因为与IE4和SDK装备在一起的版本不但要支持Java1.1事件模式，而且还要支持1.0事件模式。我猜想，创建与这两个版本都兼容的方案是有可能的，就如Java1.0的applet能够在Java1.1环境中工作一样。但是，在Java1.0.2版本的AFC发布之前，所有的结果都不会明朗。
同样，自从上篇文章刊出之后，Microsoft发布了Macintosh和Solaris平台的IE4的预备版。根据Microsoft公司的CharlesFitzgerald的说法，与这两个版本装备在一起的AFC与Windows环境下的IE4所带的AFC可以兼容。AFC的版本可以互相兼容，这就答应开发跨操作系统平台的AFC解决方案，但仍不能获得跨Java虚拟机(cross-Javavirtualmachine)的解决方案。(HP-UX和AIX版本的IE4在不久的将来也能得到。)
在此值得提一提的另一条信息是：由于AFC类并不能实现系列化(“serializable”)，它们不能象bean兼容工具应用JavaBean组件一样，被直接应用。它们目前的应用仍停留在源码级别上，而且能够在将来提供系列化功能，但是，Microsoft仍未决定开发AFC组件beans。
Locale的变化
在前一篇文章中，谈到了locale类中新增的大约50个公共实例变量，以及在java.text.resource包中新增的支持文件。虽然locale实例变量是Microsoft类库专用的，但是，给locale对象提供支持的Java类，却并不是专门针对Microsoft环境的。这就意味着你仍可以利用日期及文本格式支持类来支持各种Locale类。但是，你不应该使用Microsoft专用的常量。因此，例如，你不应当使用Microsoft专用的Locale.FINNISH常量，而应当利用newLocale("fi","FI")或newLocale("fi","")来创建一个新的Locale对象。
RMI
Microsoft提供了应用于其Java虚拟机上的Sun的RMI类，以免你丢失了上一篇文章的资源链接。这点在表面上已于今年八月就已完成，但假如你不知道查找rmi.zip，你将发现查找是十分困难的。现在，它已和其它Java资源列在一起，可以从Microsoft公司得到。然而Microsoft并不提供任何支持，为了使用与IE4相应的类，它们必须从本地安装。任何一个想利用RMI的applet，不能从Internet上下载RMI类。换句话说，RMI类必须从可靠来源获得(从本地装入)。
动作差别
许多读者指出了另外一些MicrosoftJava实现的动作差别，而且有的读者甚至还创建了Web站点以展示与此相关的问题。在第一篇文章中，由于我主要关注的是API的差异，因此有些问题我并没有提及。在更深入地使用MicrosoftJava类的过程中，有些读者发现了更多的问题，这种情况我早有所料。作为一个开发者，我们应当意识到这些问题，并且在可能的情况下绕开它们。Microsoft已经声明，有些差别已被当作bug，并且加以了改正。在被改正的JVM发布之前，了解这些问题是有好处的，至少你不必不知所措地去到处乱找错误的来源。
untrustedapplets及框架中的菜单显示
被读者指出的第一个问题与untrustedapplet被打开时框架中的显示菜单有关。这一错误可以在http://www.sc-systems.com/public/misc/IE4MenuBug/这一地址看到。在IE4中，一个untrustedapplet的警告信息看来占据了框架用于显示菜单条的空间，然而当用Netscape浏览器和InternetExplorer3.0时，它却显示正常。尽管这个测试显示的是在非凡情况下IE4可能出现的错误，但IE4中用于显示和测定框架大小的方法是不标准的。大多数的读者利用setSize()和setVisible()来显示框架时，不可能遇上这种错误。而相反的是，频繁调用addNotify(),setSize(),并接着调用setVisible()的开发者将会遇上麻烦。你不必直接调用addNotify()以创建一个组件的同位类(peer)。假如一个程序需要用到只有同位类才能提供的信息，则可以重载addNotify()方法，先让这个新的方法调用super.addNotify()，再在这个重载的方法中，利用由super.addNotify()获得的信息。
利用IE和SOCKS代理服务器
读者所指出的第二个问题与IE利用SOCKS代理服务器的配置有关。假如IE被配置成利用SOCKS代理服务器方式，那么从“jview”(SDK的Java命令行载入程序）启动的Java应用程序将利用这个代理服务器。假如本地的防火墙不知道Internet的网络配置，那么当SOCKS服务器查询本地主机的地址时，它执行这个查询，认为它与通常的Internet名字空间不相符，因而失败。很名显，Microsoft实现抽象的SocketImpl类，以及对私有的PlainSocketImpl类的进行包装时，先搜索Windows的注册信息，并利用代理服务器主机作为主机名字解析。一但失败，与Microsoft虚拟机捆绑在一起的socket存取就会抛出一个SocketException异常。但在JDK和Netscape环境下，这些工作都是正常的。想得到此问题的更完全描述，可参见http://www.findmail.com/listsaver/advanced-java/4873.Html。
有一个方法可以绕过这个问题，但是请记住，这个问题对于Microsoft最新的IE4和JavaSDK版本来说，并不是一个新问题。AscentTechnology的SundarNarasimhan，一个分布式软件开发者，提供了下面的方法：通过下面的一段代码，删除“socksProxyHost”系统属性，以避免用到SOCKS代理。
Propertiesp=System.getProperties();
if(System.getProperty("java.vendor").equals("MicrosoftCorp.")){
p.remove("socksProxyHost");
}
编译差异：Sun的javac和Microsoft的jvc
我们碰到的第三个问题与javacJDK编译器和jvcSDK编译器二者之间的动作差别有关。当一个内嵌类存取一个外部类的私有变量时，Sun的Java编译器对这种情况的处理，不同于Microsoft的编译器。这看起来意味着，当创建跨Java系统方案时，你不应该通过内嵌类来存取其外部类的私有变量，相反的是，你应该或者为这个变量创建一个存取例程，或者将这个变量变成包私有变量。
还发现的其它问题：
Toolkit.beep()在untrustedapplets中不答应使用
List.setForeground()/setBackground()这两个方法被省略
有关Netscape的问题
在有关Netscape的小问题中，我已提到过Netscape通过其Communicator补丁，对其Java类库的改变──及这些改变可能带来的一些麻烦。Sun已经了解到这些问题，而且Netscape也已签署了一个协议，保证在最终版本的发布前，改正这些错误。在最终版本的发布之前，假如你利用了Netscape的Visualjavascript工具(当前它仍还是beta版本)，借助JavaBean来创建解决方案，那么你就会用到JavaScript的非标准的Java扩充。这意味着，由VisualJavaScript工具创建的程序，可能在Communicator环境之外不能工作。与对付Microsoft的专有扩充一样，在这些问题被改正之前，避免使用Netscape的专有扩充。
结论
在对Microsoft的JavaSDK和IE4作了更进一步的考查之后，我的结论没有改变。当你想创建一个跨Java平台的实现方案时，假如利用了Microsoft最近推出的新版本，你就可能发现这一工作变得更加困难。AFC仍然不是一个跨平台的实现，而且我们不可能在很短的时间内，得到它对JavaBeans的支持，尽管Java1.0.2版本的AFC发布即将来临。同样地，假如只用于Microsoft环境，Locale常量的增加就不会象最初所说的那么麻烦，而从Microsoft公司，你也可以得到RMI类。
的确，在Microsoft的Java实现中，存在着动作差别。每个人都希望在一个版本推出之前，更多的象此类的问题和差别能够得到解决。由于面临最基本的问题，可以看得出，Microsoft已经能够对开发者所关心的问题作出更为积极的响应。对于JavaSoft，Microsoft已经提供了付款支持服务(假如这个问题最终被认明是bug，则将不收取技术支持费用。)最后，值得一提的是，Microsoft在10月未发布的Java环境修订版中，对前面所说的菜单和Toolkit.beep()bug都做出了修正。这个版本还增加了最初版本中遗漏了的ByteArrayOutputStream方法。假如你还被这些问题困绕的话，你可以在http://www.microsoft.com/java/vm/vmdownload.htm页面下，下载这一新的版本。
资源
Microsoft的JavaSDK2.0
http://www.microsoft.com/java/sdk/20/relnotes/intro.htm
Microsoft的AFC
http://www.microsoft.com/java/afc/
Java不兼容性检测代码
http://www.endware.com/twm/nojava/noj-dev.htm
Microsoft提供的应用于MicrosoftJava虚拟机的Sun′sRMI类
http://www.microsoft.com/java/resource/misc.htm
DavidCarr′的文章
http://www.webweek.com/1997/10/20/news/19971020-java.html
有关AscentTechnology的信息
http://www.ascent.com
内嵌类对封装它的类的私有成员的存取
http://www.microsoft.com/java/sdk/20/tools/jvcread.htm
Microsoft的付款支持页面
http://www.microsoft.com/java/sdk/20/support.htm
