Print-friendly Version

リリースノート Java 2 SDK, Standard Edition, Version 1.3.1

目次

概要
Java 仮想マシン
フォントプロパティ
Solaris での Xserver のバグ
RMI
CORBA、RMI-IIOP、および Java IDL
Java 2D テクノロジ
ドラッグ＆ドロップ
Accessibility
AWT および Swing
JDBC
セキュリティ
ネットワーク
Java Plug-in コンポーネント
各国語対応に関する注
ドキュメント
Solaris 2.6 上でツールが日本語 PCK ロケールの文字列を変換できない
繁体字中国語フォントの問題 Windows 2000 のサポート
Windows NT でのインストール

Java 2 SDK, Standard Edition, バージョン 1.3.1 (J2SDK 1.3.1) は、以前のバージョンで確認されたバグの修正を含むメンテナンスリリースです。バグ修正の詳細は、以下を参照してください。

最初の 1.3.1 リリースで修正されたバグ

以下も参照してください。

続く 1.3.1 アップデートリリースで修正されたバグ

さらに、J2SDK 1.3.1 には以下の拡張機能が追加されています。

• Java 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 などの以前のリリースでは、個別にダウンロードして入手しなければなりませんでした。

Java Plug-in 製品のドキュメントについては、Java Plug-in の Web サイトを参照してください。

J2SDK 1.3.1 の完全なドキュメントセット (英語版) は、ダウンロードが可能です。新しいオンラインドキュメントも参照してください。「Tuning Garbage Collection with the 1.3.1 Java Virtual Machine」

以降に、重要なバグの修正や既知のバグとその回避策、およびこのリリースの使用上の注意事項や提案事項など、J2SDK 1.3.1 のユーザにとって有益と思われる情報を記述します。

Java 仮想マシンに関して、次の注意事項があります。

• Linux ユーザの場合 - 新しい glibc-2.2.x ライブラリは初期スレッドスタックのサイズが 6MB を超える場合、正しく処理できません。新しいライブラリを使用するいくつかの Linux プラットフォームで、セグメンテーション違反が発生することがあります。そのようなプラットフォームには、Red Hat 7.0、Mandrake 8.0、SuSe 7.2、および Debian 2.2 があります。この問題は、Red Hat 6.1 および Red Hat 6.2 など、glibc-2.1.x を使用する Linux プラットフォームでは発生しません。また、異なるスレッドスタックレイアウトを使用するため、Red Hat 7.1 でも発生しません。この問題は、バグ 4466587 で追跡されています。

  回避策 - bash シェルの場合は "ulimit -s 2048"、tcsh の場合は "limit stacksize 2048" を使用して、初期スレッドスタックを 2MB に制限します。

• libsafe ライブラリの 1.x バージョンの制限については、Avaya Labs Research を参照してください。 この制限により、Java 2 SDK ツールは障害が発生し、 "Invalid initial heap size: -Xms8m" というメッセージが表示されます。 -Xms オプションを明示的に設定して、java アプリケーション起動用プログラムを使用しても、同様に失敗します。 この制限は、libsafe ライブラリの最新のリリースであるバージョン 2.0 で修正されています。 このバージョンは、http://www.research.avayalabs.com/project/libsafe/ からダウンロードできます。

• Linux プラットフォームでは、入出力操作に関連したファイルがクローズされている場合に、入出力操作を待っているスレッドが起動しません。この問題はバグ 4344135 で追跡されています。この問題を回避するためには、J2SE_PREEMPTCLOSE 環境変数を 1 に設定してください。

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• バグ 4323062: Windows NT Service が Java VM を組み込んでいる場合、ユーザのログアウト時に異常終了する

  このバグは、J2SDK 1.3.1 で修正されました。この修正を有効にするには、-Xrs コマンド行オプションを JVM に渡す必要があります。この修正により、必ず J2SDK 1.3 のシャットダウンフック機構が無効になり、sun.misc.Signal クラスの使用が禁止されるため、コマンド行引数を追加する必要があります。詳細については、Bug Prade の Evaluation の (特に) 最後のセクションを参照してください。

  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.

  
  

  この問題は、理論上は Microsoft Windows や Solaris プラットフォーム上でも発生する可能性がありますが、ほとんどの場合 Red Hat Linux 7.1 SMP 上で発生します。

  回避策: - アプリケーションの main メソッドの末尾に、次のような明示的な終了呼び出しを追加してください: Runtime.getRuntime().exit(0)

• Red Hat 7.1 にオートマウントされた NFS を介して Java プラットフォーム上でコードを実行すると、Red Hat 上の dlopen() が頻繁にクラッシュします。 この問題は、NFS オートマウンタが原因となっています。 mount -t nfs コマンドを使用してディレクトリを明示的にマウントすると、この問題は発生しなくなります。

このリリースでは、フォントプロパティに関して以下の問題が発生しています。

• 6.1 以外のバージョンの Red Hat Linux を使用する場合は、font.properties ファイルが特定の Symbol/Dingbats 文字を特定の AWT コンポーネント上に正しく表示しない可能性があります。この問題を回避するには、修正した font.properties ファイルで <JAVA_HOME>/jre/lib/ にある該当ファイルを置き換えます。

• バグ 4419794 により、Solaris 8 (Intel アーキテクチャ) の UTF-8 ロケールでフォントプロパティが警告メッセージがスローする可能性があります。Intel ハードウェア上の Solaris 8 で UTF-8 を使用する必要がある場合は、システムを Solaris 8 Update Release 4 にアップデートしてください。このリリースでは、問題が修正されています。

Solaris での Xserver のバグにより、Java プログラミング言語で書かれたアプリケーションがフォントを参照すると、システムクラッシュが発生します。この問題のバグレポート ID は 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 の Web サイトで調べることができます。

このリリースで RMI (Remote Method Invocation) 機能に加えられた重要な変更点を以下に示します。

• リモート呼び出しの受信には java.net.SocketPermission による受信アクション ("accept") の指定が必要
  以前の J2SDK 実装では、バグのため、アクセスコントロールコンテキストがソケット接続のリモート java.net.InetAddress およびポートに対して java.net.SocketPermission による受信アクション ("accept") の指定を持たない場合でも、あるアクセスコントロールコンテキストのリモートオブジェクトをエクスポートしてから、特定のソケット接続上でそのオブジェクトのリモート呼び出しを受信できませんでした。

  このバグは修正されたため、場合によっては、リモートオブジェクトをエクスポートするコードを正しく機能させるために、以前の実装では持っていなかったアクセス権をそのコードに対して与える必要があります。

  デフォルトのセキュリティポリシーファイルの構文を使ってアクセス権を与える例として、terrier.east.sun.com というホストからソケット接続を受け入れるアクセス権を、(適切なコードソースの許可エントリでの) 以下のアクセス権エントリで表すことができます。

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

  java.net.SocketPermission のドキュメントに記述されているように、ホストの指定がワイルドカード "*"で始まる場合、ホストのソケット接続を受け入れるためのアクセス権は、許可エントリでの以下のアクセス権エントリで表すことができます。

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

• アンエクスポートされたリモートオブジェクトはガベージコレクトされない
  以前の実装では特定の状況下で、リモートオブジェクトが明示的にアンエクスポートされたあとでも RMI ランタイムはリモートオブジェクトを強く参照していました。このバグは、明示的にアンエクスポートされたリモートオブジェクトを RMI ランタイムが参照しないように修正されました。

• 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 クライアントが Serializable インスタンスに送信しようとし、そのインスタンスが自身の writeObject または readObject メソッドで writeUTF または readUTF を使用する場合、MARSHAL 例外が発生します。同様に、最初に J2SDK 1.3.1 サーバが J2SDK 1.3.1 クライアントに接続し、次に J2SDK 1.3 クライアントが同じ型のクラスのインスタンスを送信しようとした場合、MARSHAL 例外が発生します。この問題のバグ ID は 4434140 です。

  回避策 - writeUTF と readUTF の代わりに writeObject と readObject を使用するように Serializable クラスを変更します。

• J2SDK 1.3 は writeUTF および readUTF 呼び出しを、wstring ではなく CORBA string にマッピングしていました。このため、8 ビットより大きな値の文字の String をこれらのメソッドを使って送信することはできませんでした。この問題は J2SDK 1.3.1 で修正されましたが、J2SDK 1.3 と通信する場合にはこの制限が適用されます。この問題のバグ ID は 4379597 です。

  回避策 - writeUTF と readUTF の代わりに writeObject と readObject を使用します。JDK 1.3.1 と J2SDK 1.3 は共に、メソッドパラメータが String のときにこれらのメソッドを CORBA wstring 呼び出しにマッピングします。

• Java 2 SDK, Standard Edition (J2SE), v 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 Web サイトのバグレポート 4365188 を参照してください。) そのため、J2SDK 1.3.1 が発展しているクラスを J2SDK 1.3 に送信しようとする場合には、相互運用性の問題が発生します。

• OMG IDL でコードを書くときに、インタフェース名をモジュール名として使用してはいけません。使用すると、複数の異なるベンダーのツールでコンパイルした場合に、その結果に一貫性がなくなる可能性があります。またその結果として、コードの移植性がなくなります。しかしたとえば、同じ名前を含むコードを Sun Microsystems が提供する IDL-to-Java コンパイラでコンパイルすれば、同一の結果を得ることができます。同じコードを他のベンダーの IDL-to-Java コンパイラでコンパイルすると、異なる結果が生成される可能性があります。

Java 2D^TM ライブラリのバグ 4178909 のため、8 ビットモードで実行中にアプリケーションが正しく表示されないことがあります。この問題が影響するのは、リブート後またはディスプレイを 8 ビットモードに設定後に初めてアプリケーションを実行する場合だけです。

DirectDraw に関係したバグもいくつかあります。DrirectDraw で問題が生じた場合は、DirectDraw をオフにすることを検討してください。

-Dsun.java2d.noddraw=true

ディスプレイドライバによっては、DirectDraw へのアクセス時に、ウィンドウを含むモニターイメージが再同期またはジャンプしたように見える場合があります。この現象が発生する場合は、問題を修正する新しいドライバが登録されているかどうかをメーカーの Web サイトで確認してください。

Java プラットフォームは、16 色表示をサポートしていません。16 色表示でグラフィックスおよび GUI コンポーネントの描画に問題が発生する場合は、色数を 256 色以上に変更してください。

次は、このリリースのドラッグ＆ドロップに関する注です。

• 以下の機能は、実装済みで動作しますが、完全にはテストされていないためこのリリースではサポートされていません。
  • ドラッグ＆ドロップ転送
    • プラットフォームネイティブまたはユーザ定義のデータ型
    • 同じ JVM* 内での、個別の ClassLoader インスタンスによってロードされた任意クラスのインスタンス
    • JVM 間または ClassLoader 間での、直列化された Java オブジェクト
  • JVM 間での RMI java.rmi.Remote サブインタフェースのリンク

• ドラッグ＆ドロップ機能の変更については、J2SE 1.3.1 のバグ 4313374 の修正で紹介されています。 新しい動作では、以前に行なったドラッグ＆ドロップ操作が完了するまでドラッグ操作はブロックされます。 J2SE の 1.3.1 より以前のバージョンでは、ほかのドラッグ＆ドロップ操作が進行中であっても、新しくドラッグ操作を開始できました。

  正しく構築されたアプリケーションは、DropTargetDropEvent.rejectDrop() または DropTargetDropEvent.acceptDrop(int) のどちらか、あるいは両方を呼び出し、DropTargetListener.drop(DropTargetDropEvent) の中で DropTargetDropEvent.dropComplete(boolean) を呼び出します。 これにより、ドラッグ＆ドロップサブシステムがほかのドラッグ＆ドロップ操作を認識して開始する前に進行中のドラッグ＆ドロップ操作が終了します。 よって、動作に関するこの変更は、記述済みのアプリケーションにとっては悪影響でしかありません。

AWT および Swing コンポーネントは、Java Accessibility API を実装する内部クラスを持ち、各コンポーネントに適したユーザ補助機能をサポートします。ただし、以下のクラスについては、このリリースではユーザ補助機能のサポートが完全には実装されていません。

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

すべてのコンポーネント対するユーザ補助機能の完全なサポートは、Java 2 プラットフォームの将来のリリースで実装される予定です。

以下は、このリリースの AWT および Swing の機能について記述しています。

• バグ 4504963 により、Windows 2000 および Windows XP プラットフォームでマウスの速度をデフォルト以外の値に設定すると、マウスの移動に対してカーソルが不規則に応答します。この問題を回避するには、[マウス] コントロールパネルでマウスの速度をデフォルト値 (有効範囲内の中間の値) に設定します。

• static メソッド Toolkit.getDefaultToolkit を呼び出すプログラムは、コマンドプロンプトを終了して復帰しません。この問題のバグ ID は 4030718 および 4403762 です。これらのバグは、J2SDK 1.4.0 Beta で修正される予定です。

  回避策 - アプリケーションの終了時に System.exit() を呼び出します。

  新しいメソッド Component.getListeners() は、PropertyChangeListener を正しく返しません。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 は、バージョン 3.5 以降の Merant DataDirect ODBC ドライバで JDBC 2.0 ブリッジを使用することを推奨しています。

以下に、このバージョンでのセキュリティ関連の注を説明します。

jarsigner ユーティリティは、コード署名証明書が自己署名されない場合に、Netscape SignTool 1.3 によって署名されたファイルを検証できます。注: 公式な Netscape コード署名証明書は、VeriSign から入手できます。これらの証明書は、VeriSign によって発行され、自己署名はされません。

Netscape SignTool 1.3 は、コード署名証明書が自己署名される場合は、証明書を署名ファイルには格納しません。また、署名ファイルが署名者の証明書を含まない場合、jarsigner は署名された JAR ファイルを検証できません。注: SignTool 1.3 自体が生成したコード署名証明書は、テスト用であり、自己署名されたものです。コード署名証明書が自己署名されたテスト用の証明書である場合に、Netscape SignTool 1.3 によって署名された JAR ファイルを jarsigner が検証できないというのは、既知の問題です。

Java 2 SDK では、アプリケーションクラスは現行の ClassLoader インスタンスによってロードされます。それによってアプリケーションクラスがインストール済み拡張機能を使用できるようになり、さらに、アプリケーションクラスパス (ユーザが指定) をブートストラップクラスパス (固定で、ユーザは通常変更しない) から分離することができるようになります。-Xbootclasspath オプションを使用すると、必要に応じてブートストラップクラスパスを無効にできます。

つまり、Java 2 SDK のアプリケーションクラスは、デフォルトですべてのアクセス権を持つのではないこということです。その代わり、そのシステムに設定されたセキュリティポリシーを基にアクセス権が与えられます。そのため、1.0 や 1.1 の元のセキュリティモデルに基づいて自らのセキュリティコードを書くようなアプリケーションでは、例外をスローしたり、Java 2 SDK で起動しなかったりする場合があります。回避策としては、そのアプリケーションをアプリケーション起動ツール oldjava で実行する方法があります。このツールのドキュメントは、java アプリケーション起動ツールのページにあります。

以下に、セキュリティポリシーと署名に関する問題の概要を示します。

• Java 2 プラットフォームが使用するデフォルトのセキュリティポリシー実装は、Java セキュリティプロパティファイル jre/lib/security/java.security の policy.provider プロパティによって指定されます。デフォルト以外のセキュリティポリシー実装を指定する場合は、デフォルト以外のセキュリティプロパティクラスファイルを新しくブートクラスパスに置く必要があります。これは、-Xbootclasspath コマンド行オプションを使って行います。このオプションの詳細は、Java アプリケーション起動ツールのリファレンスページを参照してください。これにより、ポリシーファイルがブートストラップクラスローダによりロードされます。新たにデフォルトポリシーファイルを、クラスパスまたは拡張機能内などの他の場所に配置すると、このファイルは取得されず、代わりに sun.security.provider.PolicyFile で提供されるデフォルトポリシーが使用されます。

• バージョン 1.2.2 以降の Java 2 SDK は、新しいクラスローディング機構を使用します。新しいクラスローダでは、Jar ファイルのパッケージに属する任意のクラスファイルを署名する場合、同じパッケージに属するすべてのクラスファイルが同じ署名者によって署名されている必要があります。パッケージ内に署名付きクラスと署名のないクラスとが混在する、または署名者の異なるクラスが存在する Jar ファイルは使用できなくなりました。Jar ファイルには、署名のないパッケージを含めることは可能です。ただし、任意のパッケージが署名付きクラスを含む場合、そのパッケージのクラスファイルはすべて、同一の署名者により署名される必要があります。この基準に従っていない既存の Jar ファイルは、このバージョンの Java 2 プラットフォームでは使用できません。

keytool ツールを使って、Base64 で符号化された証明書をインポートまたは印刷することができます。ただし、この処理を行うためには、証明書ファイルの末尾に改行文字が挿入されていなければなりません。証明書ファイルの末尾に改行文字がない場合は、サポート対象外の符号化であることを示す例外 CertificateException がスローされるか、「入力の構文解析に失敗しました。」や「入力は X.509 証明書ではありません。」などの意味のエラーメッセージが表示されます。

このようなエラーメッセージや例外が発生する場合は、ファイルの末尾に改行文字が存在しない可能性があります。その理由の 1 つとして、証明書発行局からの証明書応答 (証明書署名要求への応答) に改行文字が含まれていないことが考えられます。

UNIX では、次のコマンドを実行することによって、ファイルの末尾に改行文字が存在するかどうかを確認できます。

    od -xc <certificate_name>

<certificate_name> は、証明書が含まれているファイル名で置き換えます。たとえば、mycert という名前のファイルを使用する場合は、次のコマンドを実行します。

    od -xc mycert

実行後、出力の末尾に「¥n」があれば、ファイルの末尾には改行文字が存在しています。「¥n」がない場合は、改行文字を挿入する必要があります。

証明書ファイルの末尾に改行文字があるかどうかわからない場合は、とりあえず段落ごとに改行文字を挿入してみてください。改行文字が余分に存在していても問題はありません。改行文字を挿入したら、-import または -printcert コマンドを再試行します。ここでコマンドが正しく実行されれば、改行文字の不足のせいでエラーが発生していたことになります。それでもまだエラーが発生する場合は、証明書に何らかの問題があると考えられます。

Base64 で符号化された証明書ファイルの末尾に改行文字を挿入したい場合は、まず任意のテキストエディタでファイルを開き、ファイルの末尾にカーソルを移動させます。次に、改行文字 (または復帰改行文字) を入力します。キーボードの Enter キーなどを押すと入力できます。

ネットワーク

このリリースのネットワーク API には、以下の既知のバグと制限があります。

• Windows 2000 上では、データグラムアプリケーションは、ソケットがクローズしていることを示す、予期しない SocketException を受信することがあります。この問題は、Windows 2000 でリモートアプリケーションが利用不能な場合の新しい動作に関連して発生します。回避策として可能性のある方法は、DatagramSocket をクローズして再度作成することです。この問題のバグ ID は、4361783 です。

• J2SDK 1.3.0 では、HTTP/1.1 クライアント実装が導入されました。Apache などの Web サーバは、チャンクの符号化応答を HTTP 1.1 クライアントに返しますが、J2SDK 1.3.0 および 1.3.1 のチャンクの符号化処理では、サーバからチャンクの応答をストリームとして送信しません。実際上は、java.net.URLConnection.getInputStream などのメソッドは、サーバの応答が完了するまで戻りません。このバグの ID は、4333920 です。
  回避策: Apache については、以下の記述を httpd.conf に追加すると問題を回避できます。

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

• HTML 4.0 の仕様では、URI (Uniform Resource Identifier) 内の非 ASCII 文字は 1 つまたは複数の UTF-8 バイトに符号化することが推奨されています。多くの既存 CGI スクリプトは、ドキュメントが受信されたエンコーディングからのバイトを使って非 ASCII 文字を処理しています。しかし、クラス URLEncoder および URLDecoder は、URI での非 ASCII 文字を処理するメソッドをサポートしません。これらのクラスは、基本となるプラットフォームのデフォルトエンコーディングで定義されている文字ではなく 1 つまたは複数のバイトを使います。このバグの ID は 4257115 です。

• クライアント側でメソッド HttpURLConnection.getResponseCode を呼び出すと、Win98 または WinNT サーバで送信された HTTP ヘッダフィールドに余分な CR がある場合に仮想マシンがクラッシュすることがあります。このバグの ID は 4258697 です。
  回避策: http サーバが HTTP 1.0 応答を送信するように設定することにより、スタックオーバーフローを回避できます。Apache については、以下の記述を httpd.conf に追加すると問題を回避できます。

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

アプリケーションがネットワーククラスを使用する場合、Winsock 1.1 で確実に動作しない可能性があります。ネットワークアプリケーションが、Winsock 1.1 を含む Windows 95 をサポートする必要がある場合は、そのアプリケーションのユーザは Winsock 2.0 を使用する必要があります。(Windows NT 4.0、Windows 2000、Windows Me、および Windows 98 は Winsock 2.0 を含んでいます。) 次の URL から Winsock 2.0 をダウンロードできます。

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

次の URL には、Winsock 2.0 コンポーネントが Windows 95 プラットフォームにインストールされているかどうかを判定するための情報が掲載されています。

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

Winsock のアップグレードを行わないと、名前の参照が失敗したときに、kernel32.dll で InetAddress.getByName がクラッシュする可能性があります。このバグの情報は、Microsoft 社の Web サイトを参照してください。

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

Java Plug-in コンポーネント

以下は、このリリースでの Java Plug-in コンポーネントに関する注です。

• J2SE 1.3.1_01a 以降、Java Plug-in は、Microsoft Windows プラットフォームで、アプレットの起動および JRE/Java Plug-in の自動ダウンロードの開始に使用する <applet> タグをサポートしています。詳しくは、Java Plug-in 開発者用ドキュメントを参照してください。

• バグ 4406285 は、1.3.1_01a 以降のバーションの Java Plug-in では修正されています。このバグは、アップレットから SSL を過剰に使用するという問題を引き起こし、その結果 Microsoft Internet Explorer で多くのメモリリークが発生していました。ただし、メモリリークは Netscape Navigator 4.x および Netscape 6 ブラウザで https を使用するアプレットでは現在もまだ発生する可能性があります。この問題はバグ 4406285 に関連するものではなく、おそらく Netscape ブラウザのセキュア https 接続に起因する個別の問題であると考えています。

• Linux プラットフォームでは、アプレットの複数のコピーを Web ブラウザから印刷することはできません。1 回印刷したら、以降印刷するたびにブラウザを閉じて再起動する必要があります。この問題のバグ ID は 4450194 です。

• Java Plug-in コンポーネントを使用して拡張機能をインストールすると、ユーザへの警告を示すダイアログボックスが表示されます。しかし、ユーザが「拒否」ボタンをクリックしても、警告ダイアログボックスが再度表示され、同じ拡張機能のインストールを承認するか拒否するかを問い合わせます。このバグは、今後のリリースで修正される予定です。

• バージョン 1.3.0_01 では、署名の検証において CA ストアは、Microsoft Internet Explorer に付属のものではなく、Sun の Java Runtime Environment に付属のものが使用されるように変更されました。このように変更されたのは、Netscape Web ブラウザで実行されるアプレットでは、Internet Explorer の CA ストアを使用できないためです。またバージョン 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 コマンドの引数として日本語文字列を使用すると、エラーが発生します。この問題を回避するには、/usr/java/bin/.java_wrapper ファイルの 89 行目を次のように変更してください。

変更前 : exec $DEBUG_PROG "$prog" $opts "$@" 変更後 : exec $DEBUG_PROG $prog $opts $@

繁体字中国語フォントの問題

このリリースには、繁体字中国語フォントに関連する以下の問題があります。

• Microsoft Windows 95 for Traditional Chinese Version 2.0 には、Java 2 SDK のフォントプロパティファイルに指定されている繁体字中国語フォントが含まれていません。このフォントがないオペレーティングシステム上で Java 2 SDK または Java 2 Runtime Environment を使用すると、[フォントが見つかりません] というメッセージが表示され、テキストが正常に表示されない可能性があります。この問題は、1996 年 10 月にリリースされた Windows 95 for Traditional Chinese Version 2.0 Second Release では発生しません。このリリースでは繁体字中国語フォントが含まれています。

• Microsoft Windows 95 上の繁体字中国語環境では、中国語文字が Swing コンポーネント上で正しく表示されません。この問題の詳細は、Java Developer Connection^SM Web サイトのバグレポート 4431319 を参照してください。

英語環境では、Java 2 SDK のバージョン 1.3.1 は、 Windows 2000 Professional、Windows 2000 Server、Windows 2000 Advanced Server でサポートされます。Windows 2000 の Datacenter Edition はサポートされません。英語以外では、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 社の次の Web サイトで問題の解決方法についての情報を参照してください。

     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 の Web サイトを参照してください。

  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 文字列上をダブルクリックし、"値のデータ" の下の強調表示された文字列を削除します。ActiveX Control ファイルのステータスが "インストールされています" になります。