版次注意事項 JavaTM 2 SDK, Standard Edition Version 1.3.1

內容

總覽
Java 虛擬機器
字型內容
Solaris 上的 Xserver 錯誤
RMI
CORBA、RMI-IIOP 和 Java IDL
Java 2D^TM 技術
拖放
可存取性
AWT 和 Swing
JDBC
安全
網路功能
Java^TM Plug-in 元件
本土化注意事項
說明文件
工具無法轉換 Solaris 2.6 上的日文 PCK 字符串
繁體中文字型問題
支援 Windows 2000
Windows NT 上安裝

Java 2 SDK Standard Edition 1.3.1 版 (J2SDK 1.3.1) 是一個維護版本，含有舊版中已知錯誤的修復。有關這些修復的詳細資料，請參閱

本版次中修復的錯誤

此外，J2SDK 1.3.1 還包含下列加強功能。

• Java^TM Plug-in 加強功能
  本版次包含高效能的 Java Plug-in 產品，配備許多新功能使其更具彈性、更易於使用及配置， 並可讓其支援 Netscape 6 瀏覽器的新的 Open JVM Interface 功能。如需詳細資訊，請參閱 Java Plug-in 新功能。這些 Java Plug-in 加強功能首先是在更新版 J2SDK 1.3.0_01 中引入。

• Java 虛擬機器中的錯誤處理功能
  J2SDK 1.3.1 中的 Java 虛擬機器具有新的錯誤處理機制， 其會在專屬碼中發生毀損時，在螢幕上列印除錯資訊。如需詳細資訊，請參閱 J2SDK 1.3.1 中的錯誤處理。

• HTML Converter 現在為 Java 2 SDK 的一部份
  現在 Html Converter 已連結為 Java 2 SDK 的一部份。 在先前的版次中（包括 J2SDK 1.3.1 Beta），只能個別下載 Html Converter。

有關 Java Plug-in 產品的說明文件，請參閱 Java Plug-in 網站。

完整的 J2SDK 1.3.1 說明文件集可以下載。 請參閱新的線上文件 Tuning Garbage Collection with the 1.3.1 Java Virtual Machine。

J2SDK 1.3.1 的使用者可能會對以下的注意事項有興趣，包括重要錯誤修復的說明、已知的錯誤和解決方案，以及有關使用本版次的其他各項要訣和建議。

下列注意事項有關 Java 虛擬機器。

• 在 Linux 平台上，若涉及 I/O 操作的檔案已關閉，等候在 I/O 操作中的執行緒將不喚醒。 這個問題被列為錯誤 4344135 進行跟蹤。欲避免此問題，將 J2SE_PREEMPTCLOSE 環境變數設定為 1。

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• 錯誤 4323062：當使用者登出時，任何內嵌 Java VM 的 Windows NT Service 都會異常中止

  在 J2SDK 1.3.1 中已修復這個錯誤。為能啟用修復版， -Xrs 指令行選項務必傳送至 JVM。額外的指令行引數是必要的， 因為修復必然會停用 J2SDK 1.3 關機追蹤點機制及禁止使用 sun.misc.Signal 類別。有關進一步的背景， 請至少參閱 Bug Parade 上的最後評估段落:

  http://developer.java.sun.com/developer/bugParade/bugs/4323062.html

• JNI 錯誤可使 JVM 在程式完成後毀壞，錯誤訊息如下。

  Another exception has been detected while we were handling last error.
  Dumping information about last error:
  ERROR REPORT FILE = (N/A)
  PC                = 0x0x41621c7a
  SIGNAL            = 11
  FUNCTION NAME     = (N/A)
  LIBRARY NAME      = (N/A)
  Please check ERROR REPORT FILE for further information, if there is any.
  Good bye.
  

  此問題大多數出現在 Linux Red Hat 7.1 SMP 上，儘管理論上他也會出現在 Microsoft Windows 和 Solaris 平台。

  解決方案 - 在應用程式的 main 方法的末尾，新增一個明確的結束呼叫：Runtime.getRuntime().exit(0)

• 在 Red Hat 7.1 上，自動安裝的 NFS 的 Java 平台上執行編碼可導致 Red Hat 上 dlopen() 中的頻繁毀壞。 此問題明顯是由於 NFS 自動安裝程式，若您確定採用 mount -t nfs 安裝目錄，此問題就不會存在。

本版次有下列有關字型內容的問題。

• 在使用 6.1 版以外的 RedHat Linux 版本時，font.properties 檔可能無法在部份 AWT 元件上適當顯示某些 Symbol/Dingbats 字元。若要更正這個問題， 請使用這個經修訂的 font.properties 檔來取代 <JAVA_HOME>/jre/lib/ 上的檔案。

• 由於錯誤 4419794，字型內容可丟出對 Solaris 8 上的 UTF-8 語言環境之警告訊息（Intel 架構）。如果您必須在 Intel 硬體上的 Solaris 8 上使用 UTF-8 語言環境，請將您的系統更新為 Solaris 8 Update Release 4，即可解決此一問題。

在用 Java 編程語言撰寫的應用程式引用字型時，Solaris Xserver 錯誤將引起系統毀壞。 錯誤報告 4391019 中說明這個問題。以下針對 Xserver 的 Solaris 修補程式將在 2001 年 6 月中旬推出，它們會有助於減少這種問題的出現。

對於 Solaris 2.6： 105633-55 (Sparc) 106248-41 (Intel)
對於 Solaris 7： 108376-24 (Sparc) 108377-22 (Intel)
對於 Solaris 8： 108652-31 (Sparc) 108653-26 (Intel)

查閱 SunSolve 網站獲得這些修補程式。

以下為本版次中對 RMI（Remote Method Invocation）功能的重要變更。

• 用於接收遠端呼叫的 "accept" java.net.SocketPermission 基本要求
  由於先前 J2SDK 實作中的錯誤，即使該存取控制內文沒有遠端 java.net.InetAddress 的 "accept" java.netSocketPermission 和給定的 Socket 連接埠 ，您仍舊可以在一個給定的存取控制內文中匯出遠端物件， 然後透過該 Socket 連接埠接收對該物件的呼叫。

  這個錯誤已經過修復；因此，在某些情況下， 可能必須對匯出遠端物件的程式碼授與比原先實作更多的許可權，以便能正常運作。

  在如何使用預設的安全政策檔語法授與這種許可權方面，舉例而言， 可以下列的許可權項目（在適當原始程式碼的授與項目中）表示接受來自 terrier.east.sun.com 主電腦之 Socket 連接的許可權：

  permission java.net.SocketPermission "terrier.east.sun.com", "accept";
  

  如 java.netSocketPermission 的說明文件中所述， 主電腦規格的開頭可能是萬用字元 "*"；因此， 可以在一個給定的授與項目中的下列許可權項目來表示接受任何主電腦之 Socket 連接的許可權：

  permission java.net.SocketPermission "*", "accept";
  

• 未匯出的遠端物件無法收集垃圾
  在先前的實作中，在某些情況下，RMI Runtime 會強力參照遠端物件，即使它很明確地並未匯出，情形也是一樣。這個錯誤已經過修復，因此 RMI Runtime 將不會參照確實並未匯出的遠端物件。

• ObjectOutputStream 置換表格效能
  在先前的實作中，有個 ObjectOutputStream 實例可記憶經置換的物件（亦即，那些由呼叫 ObjectOutputStream.replaceObject 或由類別定義的 writeReplace 方法所傳回的物件），其方法為使用線性搜尋來判定物件是否經過置換。 因此，如果在一個給定的串流中所置換的物件數很大， 則對每一個已序列化的新物件的搜尋代價會成為驚人的耗費。這個錯誤已經修復， 因此現在該實作使用更有效率的演算法來記憶物件置換。這項對物件序列化實作的修復亦有助於配置 RMI 引數和回覆值期間物件置換的可調整性。

下列註解是有關本版次中的 CORBA、RMI-IIOP 和 Java IDL 功能。

• Sun ORB 未經測試與來自其他供應商之 ORB 的連接操作能力，且 Sun ORB 並不保證適用於其他供應商的 ORB。

• 如果 J2SDK 1.3.1 伺服器先與 J2SDK 1.3 從屬站連接， 然後 J2SDK 1.3.1 從屬站嘗試傳送「可序列化的」實例（其分別在其 writeObject 或 readObject 方法中使用 writeUTF 或 readUTF），則會發生 MARSHAL 異常狀況。同樣地，如果 J2SDK 1.3.1 伺服器先與 J2SDK 1.3.1 從屬站連接，然後 J2SDK 1.3 從屬站嘗試傳送相同類型之類別的實例，則將會發生 MARSHAL 異常狀況。這個問題被列為錯誤 4434140 進行追蹤。

  解決方案 - 將「可序列化的」類別變更為使用 writeObject 和 readObject 而非 writeUTF 和 readUTF。

• J2SDK 1.3 會映射 writeUTF 和 readUTF 呼叫至 CORBA 字串，而非 wstrings。因此，大於 8 位元的字元 String 無法使用這些方法來傳送。在 J2SDK 1.3.1 中已解決這個問題，但若與 J2SDK 1.3 通信，則仍有相同的限制。這個問題被列為錯誤 4379597 進行追蹤。

  解決方案 - 使用 writeObject 和 readObject 而非 writeUTF 和 readUTF。當方法參數為 String 時，JDK 1.3.1 及 J2SDK 1.3 都會將這些映射至 CORBA wstring 呼叫。

• 隨 J2SDK 1.3.1 出貨的 Java ORB 包含修訂方案， 支援對可序列化類別的開展性變更，如 Java 序列化規格所指定。

  由於這項支援，J2SDK 1.3.1 及將來的 J2SDK 版次都可處理類別發展。比方說，如果在 J2SDK 1.3.1 中 提供的類別 V 在將來的 J2SDK 版次中開展，就可以在 J2SDK 1.3.1 上執行的應用程式從屬站（傳送/接收類別 V） 與在將來的 J2SDK 版次中執行的伺服器（接收/傳送開展的類別 V）交互運作，反之亦然。

  不過，舊版 J2SDK 1.3.0 中有防止類別開展的錯誤。 （例如，請參閱 Java Developer Connection^SM 網站上的錯誤報告 4365188）。 因此，當 J2SDK 1.3.1 嘗試傳送任何已開展的類別給 J2SDK 1.3 時，將會有連接操作能力問題。

• 當撰寫 OMG IDL 程式碼，請不要使用介面名稱做為模組的名稱。這麼做會有風險，在應用不同供應商的工具進行編譯時可能會產生不一致的結果，因而危及程式碼的可攜性。例如，從 Sun Microsystems 使用 IDL 對 Java 編譯程式編譯包含相同名稱的程式碼，會產生一個結果。使用另一個供應商的 IDL 對 Java 編譯程式所編譯的相同程式碼則可能產生不同的結果。

在 8 位元模式下執行時，Java 2D^TM 程式庫中的錯誤 4178909 有時會使應用程式無法正確顯示。這個問題應只影響應用程式在重新啟動或顯示模式設為 8 位元之後的第一次執行時。

還有一些與 DirectDraw 相關的錯誤。如果您遇到 DirectDraw 問題，應考慮關閉 DirectDraw：

-Dsun.java2d.noddraw=true

某些顯示器驅動程式將會導致在存取 DirectDraw 時，監視器影像（包括視窗）會再同步或跳動。如果您看到這種情況，請查看製造商的網站是否有新版的驅動程式可解決問題。

Java 平台不支援 16 色顯示器。如果您在 16 色顯示上繪製圖形和 GUI 元件時有問題， 請嘗試將色彩深度變更為 256 色或以上的模式。

下列功能已經過實作並可運作，但未經完整測試，且在本版次中並不支援。

• 拖放轉送下列各項：
  • 平台原生的資料類型及（或）使用者定義的資料類型
  • 在同一個 JVM* 內，由 ClassLoader 實例所載入的任意類別的實例
  • JVM（或 ClassLoaders）之間的已序列化的 Java 物件
• JVM 之間的 RMI java.rmi.Remote 子介面的鏈結

AWT 和 Swing 元件具有內部類別，該類別實作 Java Accessibility API，並提供適合元件的可存取性支援。不過，在本版次中並沒有完整實作下列 AWT 類別的可存取性支援：

java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

在將來的 Java 2 平台版次中，將會實作所有元件的完整可存取性支援。

下列註解是有關本版次中的 AWT 和 Swing 功能。

• 呼叫靜態方法 Toolkit.getDefaultToolkit 的程式不會終止及傳回命令提示。這個問題被列為錯誤報告 4030718 和 4403762 進行追蹤，將會在 J2SDK 1.4.0 Beta 中解決。

  解決方案 - 當您的應用程式完成時，請呼叫 System.exit()。

• 新的 Component.getListeners() 方法無法傳回 PropertyChangeListeners。如果您已使用 addPropertyChangeListener() 新增接聽器，

  myComponent.getListeners(PropertyChangeListener.class)
  

  將會傳回空陣列。

• 錯誤 4199374 與 JWindow 物件的焦點管理問題有關。特別是，這個錯誤 會使 Component.requestFocus() 無法提供焦點給 JWindow 中的元件。這個錯誤已在更新版 J2SDK 1.2.2_05 和 J2SDK 1.3.0_02 中修復。不過，在 J2SDK 1.3.1 中並未加以修復。

在 Windows NT 上，JDBC 2.0 橋接支援 ODBC 2.x 和 ODBC 3.x 驅動程式管理程式和驅動程式。JDBC 2.0 橋接經測試僅適用於 ODBC 3.x 驅動程式管理程式以及 ODBC 2.x 和 3.x 驅動程式。

Merant 建議 JDBC 2.0 橋接與 Merant 的 DataDirect ODBC 3.5 或以上版本的驅動程式一起使用。

下列為有關本版次的安全相關問題。

如果編碼簽章的憑證不是自簽憑證，jarsigner 公用程式可驗證 Netscape SignTool 1.3 所簽章的檔案。 請注意，您可向 VeriSign^TM 取得正式的 Netscape 編碼簽章憑證。該憑證是由 VeriSign 發出。它們不是自簽憑證。

如果編碼簽章的憑證是自簽憑證，則 Netscape SignTool 1.3 不會將憑證置於簽章檔中， 同時如果簽章檔不包含簽章者的憑證，jarsigner 無法驗證已簽章的 JAR 檔。請注意， SignTool 1.3 本身所產生的編碼簽章的憑證僅供測試，且不是自簽憑證。 有一個已知的問題是，如果編碼簽章的憑證是自簽測試憑證，則 jarsigner 無法驗證 Netscape SignTool 1.3 所簽章的 JAR 檔。

在 Java 2 SDK 中，應用程式類別是由實際的 ClassLoader 實例載入。這使得應用程式類別能夠使用已安裝的延伸項目，並將應用程式類別路徑（由使用者指定）與 bootstrap 類別路徑（其為固定的，且使用者通常不應加以修改）分開。必要的話，可使用 -Xbootclasspath 選項來置換 boostrap 類別路徑。

不過，這表示在 Java 2 SDK 中，依預設，應用程式類別已不再具有所有的許可權。相反的，是依據已配置的系統安全政策來授與其許可權。這可能導致某些依據 1.0/1.1 中的原始安全模型來撰寫其自己的安全碼的應用程式丟出異常狀況，且不在 Java 2 SDK 中啟動。有一個解決方案是使用 oldjava 應用程式啟動程式來執行這些應用程式，請至 Java 應用程式啟動程式的參照頁 。

下列注意事項彙總安全政策和簽章的相關問題。

• Java 2 平台所使用的預設安全政策實作是由 Java 安全內容檔 jre/lib/security/java.security 中的 policy.provider 內容所指定。如果您指定非預設的安全政策實作， 則必須將您新的、非預設的安全內容類別檔置於 bootclasspath 上。您可使用 -Xbootclasspath 指令行選項來執行此動作。 有關此選項的資訊，請參閱 Java application launcher 參照頁。 這將會導致原則檔由 bootstrap 類別載入器所載入。如果新的預設原則檔是置於其他位置（例如在類別路徑或延伸項目上）， 則它將不會被取用，而會改用 sun.security.provider.PolicyFile 中提供的預設原則。

• 從 1.2.2 版開始，Java 2 SDK 使用新的類別載入機制。在新的類別載入器下， 如果任何屬於 Jar 檔中的套件的類別檔已被簽章，則屬於同一個套件的所有類別檔都必須由同一個簽章者簽章。已再也不可能使用其中某些套裝軟體類別已簽章、而其他類別未簽章或由不同的簽章者簽章的 Jar 檔。Jar 檔仍可包含未簽章的套件。然而， 如果有任何套件包含已簽章的類別，則該套件的所有類別檔都必須由同一位簽章者簽章。在本 Java 2 平台版本中，將無法使用未符合此標準的現有 Jar 檔。

目前 keytool 工具可從檔案匯入或列印 Base64 編碼的憑證，不過該檔案必須以換行 (linefeed) 終止。 如果憑證檔的結尾處沒有換行，而您嘗試匯入或列印憑證， 則會出現「不受支援的編碼」CertificateException，或 keytool 錯誤訊息，例如「無法剖析輸入」或「輸入不是 X.509 憑證」。

如果出現這種訊息或異常狀況，則問題可能是遺漏終止換行。會發生這種情況的一種原因，是有時「憑證管理中心」所回覆的憑證（回應憑證簽章要求）並不包含終止換行。

在 UNIX 中，您可執行下列指令來判定檔案是否具有終止換行：

    od -xc <certificate_name>

其中 <certificate_name> 是內含憑證之檔案的名稱。比方說，如果檔案的名稱為 mycert，則指令將會是

    od -xc mycert

如果產生的輸出在最尾端處含有一個 "\n"（不帶雙引號）， 則在結尾處已有一個換行指令。若非如此，可新增一個換行指令。

如果您不確定憑證檔是否包含終止換行， 您可在後續的每個段落中都新增換行（新增更多也無妨）， 然後重試 -import 或 -printcert 指令即可。如果指令現在可行，則問題就是遺漏換行。 如果仍然出現錯誤，則有不同的憑證問題。

若要新增換行至 Base64 編碼之憑證檔的結尾， 請在任一文字編輯程式中開啟檔案、將游標置於檔案的最尾端， 然後新增換行（或回車換行），例如按鍵盤上的 Enter 鍵即可達成。

網路功能

本版次在網路功能 API 方面有下列的已知錯誤和限制：

• 在 Windows 2000 上，資料包傳遞應用程式可能會收到非預期的 SocketException，指出 Socket 已關閉。這是在無法使用遠端應用程式時，與 Windows 2000 中的新行為相關的問題。可能的解決方案為關閉並重建 DatagramSocket。這個問題被列為錯誤 4361783 進行追蹤。

• J2SDK 1.3.0 引介了 HTTP/1.1 從屬站實作。 諸如 Apache 等 Web 伺服器會傳回經分段、編碼的回應給 HTTP 1.1 從屬站，但是 J2SDK 1.3.0 和 1.3.1 的分段編碼處理並不串流來自伺服器的分段回應。實際上，這表示直到伺服器的回應完成， 諸如 java.net.URLConnection.getInputStream 等方法才會傳回。錯誤 4333920 中說明這個問題。
  解決方案： 若為 Apache，其解決方案為將下式置於 httpd.conf 中。

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

• HTML 4.0 規格建議「一致性資源識別碼 (Uniform Resource Identifiers, URI)」中的非 ASCII 字元應以一或多個 UTF-8 位元組編碼。許多現有的 CGI Script 是使用以其接收文件之編碼中的位元組來處理非 ASCII 字元。不過，類別 URLEncoder 和 URLDecoder 並不支援這些處理 URI 中之非 ASCII 字元的任一方法。 相反的，這些類別會依據基礎平台之預設編碼中定義的用一或多個位元組替換字元。這是錯誤 4257115。

• 當 Win98 或 WinNT 伺服器所傳送的 HTTP 標題欄位中有額外的 CR 時，呼叫從屬站上的方法 HttpURLConnection.getResponseCode 會導致虛擬機器損毀。 這是錯誤 4258697。
  解決方案： 將 HTTP 伺服器配置為傳送 HTTP 1.0 回應，可避免行堆疊溢位。若為 Apache，可將下式置於 httpd.conf 中來完成這項動作。

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

如果您的應用程式使用網路功能類別，則其在 Winsock 1.1 下可能無法穩定執行。如果您的網路功能應用程式必須支援 Windows 95（其包含 Winsock 1.1），您會希望應用程式的使用者備有 Winsock 2.0（Windows NT 4.0、Windows 2000、 Windows ME 和 Windows 98 都包含 Winsock 2.0）。您可從下列網址下載 Winsock 2.0：

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/

下列 URL 含有關於如何判定 Windows 95 平台上是否安裝了 Winsock 2.0 元件的資訊：

http://support.microsoft.com/support/kb/articles/Q177/7/19.asp

若沒有 Winsock 升級，則當名稱查閱失敗時，則 InetAddress.getByName 有可能會在 kernel32.dll 中損毀。關於此錯誤的資訊，請參閱 Microsoft 網站。

http://support.microsoft.com/support/kb/articles/Q176/3/54.ASP

Java^TM Plug-in 元件

下列注意事項是有關本版本中的 Java Plug-in 元件。

• Linux 平台上，可從 web 瀏覽器列印多個 applet。瀏覽器務必在每次列印後關閉並重新啟動。 這個問題被列為錯誤 4450194 進行追蹤。

• 當透過 Java Plug-in 元件安裝延伸項目時， 將會出現一個警告對話框，警示使用者事實情況。 然而，如果使用者按一下「拒絕」按鈕，有時此警告對話框仍然可能會重新出現， 詢問使用者要核准或拒絕同一個延伸項目的安裝。在將來的版次中將會修復這個錯誤。

• 在 1.3.0_01 版中，簽章驗證已改為使用 Sun Java Runtime Environment 隨附的憑證 CA 儲存庫，而非使用 Microsoft Internet Explorer 隨附的儲存庫。進行這項變更的原因是 Internet Explorer 中的憑證儲存庫無法用於 Netscape Web 瀏覽器中的 Applet。其他錯誤- 1.3.1 版中已引入處理碼來處理無法驗證的簽章。請參閱錯誤報告 4424604。

本土化注意事項

有關本版次中的國際語言環境支援的一般資訊，請參閱本土化注意事項。

說明文件

下列註解是有關本版次的文件問題。

• 由於錯誤 4459595，該版次 API 規格中 Serialized Form 頁包含一些到私有類和私有包類檔案的毀壞連結。

• 請參閱新的線上文件 Tuning Garbage Collection with the 1.3.1 Java Virtual Machine。

工具無法轉換 Solaris 2.6 上的日文 PCK 字符串

採用日文字串作為 Solaris 2.6 ja_JP.PCK 語言區 java 指令的參數時發生錯誤。 若要解決此問題，請將行 89 /usr/java/bin/.java_wrapper 從

exec $DEBUG_PROG "$prog" $opts "$@"

變為

exec $DEBUG_PROG $prog $opts $@

繁體中文文字問題

下列為本版本中存在的已知繁體中文字型問題。

• Microsoft Windows 95 繁體中文 2.0 版並不包含 Java 2 SDK 的字型內容檔中指定的 繁體中文字型。在該作業系統上使用 Java 2 SDK 或 Java 2 Runtime Environment 將會導致「font not found」警告，且文字的顯示可能不正確。 在 1996 年 10 月發行的新版 Microsoft Windows 95 繁體中文 2.0 版第 2 版次上並不存在這個問題，且已包含指定的字型。

• 在 Microsoft Windows 95 上的繁體中文環境中， 中文字元在 Swing 元件上的顯示並不適當。 有關此問題的詳細資料，請參閱 Java Developer Connection^SM 網站上的錯誤報告 4431319。

在英文語言環境中，Java 2 SDK 的 1.3.1 版受 Windows 2000 Professional、 Windows 2000 Server、Window 2000 Advanced Server 支援。Windows 2000 的 DataCenter 修訂版則不受支援。在非英文語言環境中， 僅支援 Windows 2000 的 Professional Edition。已知的 Windows 2000 問題包括：

• Windows 2000 和多重監視器支援 - 在 Windows 2000 平台上，多重監視器尚未完全運作。 特別是，只有在所有的監視器都設為 256 彩色模式時，256 彩色模式的操作方式才會正常。極力建議採用 16 位元（或更高）色彩模式。

• 若您在安裝期間在 Windows 2000 上看到下列錯誤訊息

     config.nt. The system file is not suitable for running MS-DOS 
     and Microsoft Windows Applications.
  

  其指出已在某些 Windows 2000 安裝上出現的 %SystemRoot%\System32\COMMAND.COM 檔問題。如果您在嘗試啟動安裝程式時，出現這則錯誤訊息，請參閱 Microsoft 網站

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp

  以取得關於解決問題的資訊。

• 處理作業當掉 - 應用程式可能因為在 Microsoft Windows 2000 Professional、Server 及 Advanced Server 作業系統上的 Ntdll 中死鎖而當掉。例如，在使用 java.lang.Process 物件的輸入和輸出串流的應用程式中就可能發生這個問題。如需詳細資訊（包括解決方法），請參閱 Microsoft Support Services 網站：

  http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Windows NT 上安裝

在安裝 Java Runtime Environment 的 1.3.1 版時，C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1 下的 ActiveX Control 檔案具有「損壞」狀態。 這只是表面問題，「損壞」狀態在任一情況下都沒有負面影響。

不過，若您因某些原因沒有損壞狀態，這裡也有一個解決方案。轉至「開始 -> 執行」，然後鍵入「regedit」。從 regedit 視窗，至登錄項「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation」。 按兩下 INF 字串，並刪除「Value data」下突出的字串。ActiveX Control 檔案將具有「安裝」狀態。

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.