續“如何避免Microsoft非標準JavaSDK的潛在

2019-11-18 15:17:36

字體：大中小

來源：轉載

供稿：網友

本文提供更多的技巧，使讀者能了解怎樣繞開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，你將發現查找是十分困難的?，F在，它已和其它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

上一篇：了解 JAVA classloader

下一篇：懸掛復合錯誤類型