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

目次

概要
Java Plug-in テクノロジ
AWT
Java 2D テクノロジ
Swing
セキュリティ
CORBA、Java IDL、および Java RMI-IIOP
仮想マシン
New I/O (NIO) API
Java Naming and Directory Interface API
Java Sound に影響を及ぼす Java Media Framework のバグ
Solaris 上での OpenWindows との適合性
Microsoft Windows でのプラットフォームのタイムゾーンの検出
アプレット使用時の注意
Windows XP の Samba マウントドライブ
Linux 上での使用時の注意
Sun ONE Studio (旧 Forte for Java) と NetBeans
ツールおよびユーティリティ
日本語ロケールに関する注記
直列化
Solaris 2.6 オペレーティング環境の非サポート
浮動小数点例外

Java 2 SDK (J2SDK), Standard Edition, v1.4.1 は、多数の機能分野で新機能の追加および拡張が行われた Java プラットフォームのアップグレードリリースです。このリリースのバージョン番号は 1.4.1-b21 です。お使いの SDK ソフトウェアのバージョンを調べるには、次のコマンドを使用してください。

java -version

詳細は以下のリンクのページを参照してください。

J2SDK 1.4.1 での変更点

最初の 1.4.1 リリースでのバグ修正 (1.4.1/fixedbugs/index.html)

以降の 1.4.1 アップデートリリースでのバグ修正

J2SDK 1.4.1 と旧バージョン間の互換性

以降は、既知のバグ、回避方法、およびこのリリースで注意すべき他の重要な問題について説明します。

Java Plug-in 1.4.1 を Netscape 6.x ブラウザに組み込んで使用すると、Java スクリプトからアプレットを起動する場合にブラウザのウィンドウが閉じてしまうなどの異常な動作が見られる場合があります。これは、ブラウザのバグで、Netscape 7.0 ブラウザを使用することにより回避できます。

「java.lang.IllegalStateException: zip file closed」という例外の発生の原因となる、Java Plug-in のキャッシュの問題が存在します。この問題については、「アプレット使用時の注意」を参照してください。

このリリースの AWT 機能に関連する注を以下に示します。

• Windows 2000 および Windows XP では、SCROLLBARS_BOTH フィールドを true に設定していても、TextArea (1.4.1/docs/api/java/awt/TextArea.html) に垂直スクロールバーだけが表示され、水平スクロールバーが表示されない場合があります。この問題については、バグレポート 4648702 を参照してください。

• アジア系言語版の Windows NT をインストールしたマシンに、英語版の Visual C++ 6.0 をインストールしている場合、TextArea コンポーネント内でのアジア系言語のテキスト描画時に、表示のがたつきが見られる場合があります。アジア系言語の Windows NT 4.0 の稼動するマシンに Microsoft Exchange または Microsoft Office 97 をインストールする場合にも、同様の現象が見られる場合があります。この問題は日本語版の Windows NT で報告されていますが、中国語や韓国語など、他の非ラテン文字版の Windows NT でも発生する可能性があります。

  問題は、これらのプログラムがアジア系言語用の Riched32.dll ファイルを英語版のファイルに置き換えてしまう場合に発生します。アジア系言語用の Riched32.dll にファイルと置き換えることにより、問題の発生を回避できます。

Microsoft Windows プラットフォームでは、J2SE 1.4.1 の Java 2D 機能は、DirectDraw および Direct3D のさまざまなオフスクリーン描画機能を使用して実装されています。このため、Direct3D ドライバにバグが存在するとシステムクラッシュ (ブルースクリーン) が発生する可能性があります。グラフィカルアプリケーション実行中にこの問題に遭遇した場合は、ドライバの更新を考慮してください。特定のカードの最新ドライバは、通常、ご使用のコンピュータ、ビデオカード、あるいはビデオチップの製造元の Web サイトから入手できます (http://www.nvidia.com、http://www.atitech.com など)。

Windows 2000 システムのサブセットで Direct3D を使用すると、システムクラッシュが発生することがあります (既知の問題)。その場合、アプリケーション起動時に、次のコマンド行フラグを指定してください。

-Dsun.java2d.d3d=false

このフラグは、Direct3D を強制的に無効にします。こうすることにより、Direct3D 固有の問題を回避します。

次のフラグも使用できます。

-Dsun.java2d.ddoffscreen=false

このフラグは、オフスクリーンイメージ (Swing バックバッファなど) の DirectDraw と Direct3D を無効にします。

それでも問題が解決されない場合は、アプリケーション起動時に次のフラグを指定してみてください。

-Dsun.java2d.noddraw=true

このフラグは、DirectDraw と Direct3D を完全に無効にします。こうすることにより、これらの API とドライバによってシステム上に生じる問題を回避します。

パフォーマンス関連のフラグについては、ホワイトペーパー『High Performance Graphics』の「Flags for Controlling Performance and Quality」の節を参照してください (PDF 形式でも入手可能)。

• 最近の Microsoft Windows プラットフォーム (Windows 2000、Windows XP) では、通常、ニーモニックは表示されません。これらのプラットフォームでは、alt キーを押すとニーモニックを表示できます。Swing の Windows Look & Feel では、alt キーを押してもニーモニックが表示されない場合があります。これは、次のコードで回避することができます。

  frame.getRootPane().getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(
       KeyStroke.getKeyStroke(KeyEvent.VK_ALT, Event.ALT_MASK, false),
       "repaint");
  

  この問題に関する詳細情報は、バグ情報 4736093 を参照してください。

• テキストコンポーネントでは、キーバインドの登録に Keymap が使用されなくなりました。これは、キーバインドが InputMap と ActionMap の組み合わせに完全に移行したためです。引き続き Keymap を使用できますが、Swing が Keymap 内のバインドを登録することはありません。詳細は、バグレポート 4682626 を参照してください。

次は、このリリースのセキュリティに関する注です。

• UNIX プラットフォームでは、Sun の SecureRandom 実装は、可能な場合 /dev/random を使って自身をシードします。この方法では、暗号化アプリケーションの起動時間を大幅に短縮できますが、カーネルエントロピプールが空の場合は遅延の原因になります。Solaris 8 でこの問題が発生した場合は、パッチ 112438-01 (SPARC) または 112439-01 (x86) がインストールされていることを確認します。<java.home>/lib/security/java.security ファイルを編集して、シード用の別の URL を指定することもできます。URL を開けない場合は、デフォルトの実装が pure Java シード実装になります。
• Sun の JSSE v1.0、v1.0.1、および v1.0.2 に存在するバグのため、DSA 署名を DSA サーバキー交換メッセージの一部に使用した場合、SSL_DHE_DSS_* 暗号スイートによりこれらの署名の不正な符号化が行われます。
  
  相互運用システムプロパティにより、アクティブな動作が制御されます。これは、Sun の JSSE 1.0.2 で導入されたプロパティです。

com.sun.net.ssl.dhKeyExchangeFix
true	適正な動作を使用する (JSSE 1.0.3 と連携可能)
false	「壊れた」動作を使用する (JSSE 1.0、1.0.1、1.0.2 と連携可能)

下位互換性を維持するため、J2SDK 1.4 以降の SunJSSE プロバイダもこのプロパティを保持します。デフォルト値は true です。

リリース	デフォルトの動作	スイッチ
J2SDK 1.4.0 以降	適正動作	true
JSSE 1.0.3	適正動作	true
JSSE 1.0.2	「壊れた」動作	false
JSSE 1.0.1	「壊れた」動作	なし
JSSE 1.0	「壊れた」動作	なし

• RSA ベースの PreMasterSecret を交換する場合、 RFC 2246-TLSv1 により、PreMasterSecret メッセージにクライアントがサポートする最新バージョンを含めるべきことが指定されています。SSL 実装の中には、適正なメッセージを送信するものがある一方で、現行セッションのバージョン番号 (不正) を送信するものがあります。大半のサーバは、どちらのタイプのメッセージも受け付けます。
  
  これらの違いは、サーバがサポートしない特定のプロトコルをクライアントが要求するかどうか、その結果としてサーバがより小さいバージョン番号を要求して、一方のメッセージタイプだけ (適正または不正) を受け付けるかどうかという点だけです。
  
  J2SDK 1.4.1 の SunJSSE を使用するサーバは、どちらのタイプのメッセージも受け付けます。
  
  J2SDK 1.4.0 の JDK 内の SunJSSE を使用するサーバは、不正なメッセージタイプだけを受け付けます (現在のところ、一般に使用されている Web ブラウザの大半は不正なメッセージを送信します)。
  
  J2SDK 1.4.1 の SunJSSE を使用するクライアントは、次のシステムプロパティを使用して、アクティブなメッセージタイプを制御できます。

com.sun.net.ssl.rsaPreMasterSecretFix
true	RFC 2246 に基づく適正動作を使用
false	不正な動作を使用

大半のサーバがいずれかのメッセージタイプを受け付ける場合、J2SDK 1.4.0 の SunJSSE を使用するサーバと連携するために、デフォルトは false になります。

リリース	デフォルトの動作	スイッチ
J2SDK 1.4.1	不正な動作	false
J2SDK 1.4.0	不正な動作	なし

Java IDL および Java RMI-IIOP の制限 - Java IDL および Java RMI-IIOP の使用時の制限に関する情報については、Limitations for Java IDL and Java RMI-IIOP マニュアル (1.4.1/docs/guide/idl/limitations.html) をお読みください。

以下はこのリリースの Java HotSpot 仮想マシン (VM) についての注です。

• J2SE 1.4.1 から、Java HotSpot Server VM は SPARC^® v8 アーキテクチャのチップでの動作をサポートしなくなりました。SPARCstation^® プロセッサファミリ (SPARCstation Workstation、SPARCstation Classic、SPARCstation 2、SPARCstation 4、SPARCstation 5、SPARCstation 10、SPARCstation 20、および SPARCstation^® Voyager プロセッサなど) が、この変更の影響を受けます。 Java HotSpot Client VM は、SPARC v8 プラットフォームでの動作をサポートします。 サーバ VM およびクライアント VM の詳細は、Java HotSpot VM のドキュメント (1.4.1/docs/guide/vm/index.html) を参照してください。

  UltraSPARC^® プロセッサは、この変更の影響を受けません。

• 内部整合性検査の一環として、VM は VirtualAlloc により返されたアドレスの妥当性を検証します。32 ビットの Windows XP x86 OS 上で稼働する VM は、ビット 24 からビット 31 がすべて 1 に設定されているアドレスを拒否するのに対し、64 ビットの XP Intel Itanium 64 上で稼働する VM は、ビット 24 からビット 63 がすべて 1 に設定されているアドレスを拒否します。32 ビットの Windows XP では、ビット 31 が 1 に設定されたアドレスは予約されているため、これは妥当な検査です。64 ビットの Windows XP ではこれは当てはまらず、非常にまれにアサーション障害が発生することがあります。この問題は、将来のリリースで修正される予定です。

• Java HotSpot VM は、メモリが完全に割り当てられていて、使用可能なスワップ空間がない場合は、そのヒープサイズを拡張できません。これは、たとえばいくつかのアプリケーションが同時に動作している場合などに起こり得ます。その場合、VM は次の例のようなメッセージを出力して終了します。

    Exception java.lang.OutOfMemoryError: requested <size> bytes
  

  このような状態になった場合は、仮想メモリをより多く割り当てたり、同時に実行するアプリケーションの数を制限したりして、利用可能なスワップ空間を増やしてみてください。または、コマンド行フラグ -Xmx と -Xms を同じ値に設定して、VM がヒープの拡張を行うことを防止するという方法もあります。ただし、使用可能なスワップ空間がない場合は、単に -Xmx の値を増加させても意味がないので注意してください。

  この問題は、バグ 4697804 として追跡中です。

次の注目すべき NIO のバグが、1.4.1 で修正されました。

• 非同期のクローズおよび割り込みが Linux 上で動作しない (バグ 4460583)。
• セレクタが Microsoft Windows オペレーティングシステム上で 63 チャンネルしかサポートしない (バグ 4503092)。

次のバグは、1.4.1 にも依然として存在します。

• ファイルロック操作の割り込みの実装が不完全である (バグ 4460065)。

NIO の情報については、NIO ドキュメントのメインページ (1.4.1/docs/guide/nio/index.html) および補足ページを参照してください。

以下の記述は、JNDI 機能に関するものです。

• JNDI/DNS サービスプロバイダは、java.naming.provider.url プロパティを使用して DNS サーバとの通信方法を設定します。 このプロパティが設定されていないか、その値にホスト名もポートも指定されていない場合、J2SDK v 1.4.1 より前のリリースでは、ホスト名およびポートがデフォルトの「localhost」および 53 にそれぞれ設定されます。J2SDK v1.4.1 で同じ環境下の場合は、DNS プロバイダは基盤となるプラットフォームで構成されたサーバを判別してその使用を試みます。たとえば Solaris または Linux の場合、プロバイダは /etc/resolv.conf ファイルを読み込みます。基盤となるプラットフォームで DNS が設定されていない場合、ホスト名およびポートはデフォルトの「localhost」のポート 53 にそれぞれ設定されます。

  この変更の影響を受けるのは、アプリケーションが配備されているプラットフォームの DNS 構成が「localhost」のポート 53 以外のサーバを使用するよう設定されているが、アプリケーションでは「localhost」とポート 53 を明示的に指定せずに使用することになっている場合です。この場合、J2SDK v1.4 から J2SDK v1.4.1 に移行すると、アプリケーションは期待されているものとは異なる DNS サーバを使用することになります。この問題を回避するため、アプリケーションで URL に「localhost」を明示的に指定するようにしてください。

• java.naming.provider.url プロパティは、JNDI/LDAP サービスプロバイダにより、LDAP サーバとの通信方法の設定に使用されます。J2SDK v1.4.1 より前のリリースでは、このプロパティの値は LDAP サーバのホスト名とポート、および使用するネーミングコンテキストのルート識別名を指定する単一の LDAP URL 文字列です。URL の構文は、RFC 2255 で指定されています。J2SDK v1.4.1 では、このプロパティの値は空白で区切られた LDAP URL のリストです。LDAP プロバイダは、接続の作成に成功し、java.naming.provider.url プロパティを適正な LDAP URL に設定できるまで、リスト内の各 URL の使用を順番に試みます。

  この変更は、RFC 2255 に指定された方法で有効な LDAP URL を 使用するアプリケーションには影響を及ぼしません。この変更の影響を受けるのは、LDAP URL 内で空白文字が有効であると見なし、この種の URL を java.naming.provider.url プロパティの値として使用するアプリケーションだけです。RFC 2255 によると、LDAP URL 内の空白文字は三重の「%20」としてエンコードする必要があります。J2SDK v1.4 以前のリリースでは、LDAP プロバイダは空白文字を URL の一部として受け付けます。J2SDK v1.4.1 では、プロバイダは空白文字を複数の LDAP URL の区切り文字として扱います。この影響を受けるアプリケーションを、J2SDK v1.4 から J2SDK v1.4.1 に移行すると、「名前が見つからない」というエラーが発生する可能性があります。この問題を回避するには、アプリケーションで、無効な URL 内の各空白文字を三重の「%20」で置き換えてください。

• JNDI/LDAP サービスプロバイダは、java.naming.provider.url プロパティを使用して LDAP サーバとの通信方法を設定します。このプロパティの値は、1 つまたは複数の LDAP URL です。LDAP URL は、初期コンテキスト内のメソッドへの名前引数として指定し、LDAP 参照の解決に使用することもできます。こうした状況では、J2SDK v1.4.1 では、ホスト名もポートも指定されていないが、識別名が URL で指定されている場合 (例、ldap:///dc=example,dc=com)、LDAP プロバイダは識別名を使用して 対応する DNS SRV レコードで設定された LDAP サーバのホスト名とポートを決定し、使用します。そのとき、次に記載されたアルゴリズムを使用します。
  http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-07.txt

  DNS からのデータを使用して接続を確立する場合、プロバイダは java.naming.provider.url プロパティを、選択したホスト名、ポート、および識別名を使用して構築された LDAP URL に設定します。

  この種の DNS レコードが存在しない場合、ホスト名とポートはデフォルトの「localhost」と 389 にそれぞれ設定されます。

  J2SDK v1.4.1 より前のシステムでは、指定されないホスト名とポートは常にデフォルトの「localhost」と 389 になります。DNS SRV レコードの使用は試みられません。

  この変更の影響を受けるのは、「localhost」のポート 389 以外の LDAP サーバを使用するように SRV レコードで DNS が設定され、かつ識別名を含む LDAP URL 内で期待される「localhost」のポート 389 を明示的に指定せずに使用する環境に配備されているアプリケーションです。この種のアプリケーションを J2SDK v1.4 から J2SDK v1.4.1 に移行すると、期待される LDAP サーバとは異なる LDAP サーバが使用されます。この問題を回避するには、アプリケーションで LDAP URL に「localhost」を明示的に指定してください。

Java Media Framework (JMF) の 2.1 以前のバージョンでは、バグ 4387291 により、J2SDK 1.4.1 を使用することでサウンドの出力に支障を来します。この問題を回避するには、JMF 2.1.1 以降のバージョンを使用してください。JMF 2.1.1 以降のバージョンではこのバグが修正されています。

Solaris オペレーティング環境で OpenWindows を使用して J2SE 1.4.1 プラットフォームを実行する場合、Java 2 プラットフォーム仕様との動作の適合性は保証されません。特に、Component.requestFocus() (1.4.1/docs/api/java/awt/Component.html#requestFocus()) メソッドなど、フォーカスの処理に関連する API は OpenWindows では正常に機能しません。この問題は OpenWindows のバグによるものです。詳細は、バグレポート 4505899 を参照してください。

このバグは、CDE ウィンドウマネージャでは発生しません。

Microsoft Windows オペレーティングシステムのインストールで、夏時間を使用しないタイムゾーン (例: 東京、大阪、札幌) を選択した場合、[自動的に夏時間の調整をする] のグローバルシステム設定がオフになります。このように設定された場合、Java ランタイムは、タイムゾーン ID (例: Asia/Tokyo) としてではなく、GMT オフセット形式 (例: GMT+09:00) でプラットフォームのタイムゾーンを検出します。このインストール上の問題を解決するには、意図的に設定をオフにする場合を除いて、インストールの終了後に以下の手順で設定を変更します。

1. コントロールパネルにある [日付と時間] を開きます。
2. [タイムゾーン] タブにある夏時間を使用するタイムゾーン (例: (GMT-08:00) 太平洋標準時 (米国およびカナダ);ティファナ) を選択し、次に [自動的に夏時間の調整をする] チェックボックスの選択をオンにしてから [適用] ボタンを押します。
3. 使用するタイムゾーンを選択し直し、[OK] ボタンを押します。

以下は、J2SE 1.4.1 プラットフォーム上でアプレットを使用する際の注意点です。

• アプレットの stop または destroy メソッドからモーダルポップアップダイアログを呼び出すことは、推奨されていません。これらのメソッド内でモーダルポップアップダイアログを使用すると、NullPointerException がスローされる、ダイアログボックスが表示されない、アプレットを破棄してもダイアログボックスが表示されたままになる、最悪の場合ブラウザがハングアップする、などの問題が発生する可能性があります。この問題は、バグ 4672707 として追跡されています。

• メソッド java.applet.getDocumentBase() (1.4.1/docs/api/java/applet/Applet.html#getDocumentBase()) は、アプレットが含まれるドキュメントが格納されたディレクトリの絶対 URL を返すことが想定されています。一方、メソッド java.applet.getCodeBase() (1.4.1/docs/api/java/applet/Applet.html#getCodeBase()) は、アプレット自体の URL を返すことが想定されています。J2SDK では、この 2 つのメソッドの動作が逆転しています。この問題は、バグ 4456393 として追跡されています。

• キャッシュを有効にした Java Plug-in を使用してアプレットを配備する場合、複数のクラスファイルが含まれている JAR ファイルにアプレットが格納されており、いずれかのクラスが javax.crypto.Cipher.getInstance() を呼び出すと、その JAR ファイルにアクセスする必要があるオペレーションにおいて「java.lang.IllegalStateException: zip file closed」という例外が発生し、オペレーションが失敗します。この問題の回避策として以下の 3 つが挙げられます。
  • Java Plug-in のキャッシュをオフにします。
  • Cipher.getInstance() を呼び出すクラスファイルを JAR ファイルに格納し、残りのクラスファイルを別の JAR ファイルに格納します。この方法で、必要な数のインスタンスを作成することができます。例 : <PARAM NAME = "archive" VALUE = "TestApplet.jar, Encrypt.jar"> この例では、Cipher.getInstance() を呼び出すクラスファイルが Encrypt.jar ファイルに格納されています。
  • 適格:w 国 (ほとんどの国が該当) に居住している場合には、JCE Unlimited Strength Jurisdiction Policy Files をインストールします。ただし、これはクライアント側での回避策であるため、大規模なアプレットの配備においては現実的でない場合があります。
  この問題は、バグ 4740901 として追跡されています。

Windows XP (32 ビットまたは 64 ビット版) で Samba マウントドライブを使用しているとき、FileOutputStream(name) コンストラクタが呼び出され、同じ名前の空のディレクトリが存在する場合、このディレクトリは削除されます。これは J2SE プラットフォームのバグではありませんが、バグレポート 4693219 として追跡されています。

以下は、Linux プラットフォーム上でこのリリースを使用する際の注意点です。

• 以下に示す問題は、マルチプロセッサシステム上で断続的に発生します。これらの問題の回避策はなく、解決するには Linux システムをアップグレードする必要があります。現在のところ、64 ビット Itanium システムの Linux 用に利用可能なパッチはありません。
  • バージョン 2.2.4 以前の glibc 2.2 のバグは、残った実行スレッドが 1 つだけになると仮想マシンを終了させる可能性があります。この問題は、バージョン 2.2 から 2.2.4 の glibc を含む Red Hat 7.0、7.1、および 7.2などの Linux プラットフォームに影響を及ぼします。この問題は、glibc 2.2.5 では修正されています。バグレポート 4656697 を参照してください。
  • Linux 2.4 SMP カーネルは重複 PID を発生することがあり、ネットワークエラーからクラッシュまで引き起こす可能性があります。この問題は、カーネル 2.4.18 では修正されています。バグレポート 4650839 および 4682743 を参照してください。
  • Linux 2.4.9 カーネルの既知のバグにより、Java プラットフォーム上で実行中のアプリケーションがすべての CPU リソースを消費し、その結果ハングすることがあります。この問題は、バグレポート 4701394 として追跡されています。

• CONFIG_IP_TRANSPARENT_PROXY オプションを使用してカーネルをコンパイルした任意の Linux バージョンでスーパーユーザとして実行する場合、API 仕様に準拠する動作は保障されません。Red Hat 6.2 ディストリビューションに同梱されているデフォルトのカーネルは、このオプションを使用してコンパイルされています。これに関連する非互換性の問題を回避するには、スーパーユーザで Java プラットフォームを使用しない、またはカーネルを CONFIG_IP_TRANSPARENT_PROXY オプションを使用せずにコンパイルした Linux オペレーティングシステムにアップグレードしてください。バージョン 2.4 のカーネルとともに提供されている Red Hat 7.1 では、この問題は発生しません。

• 日本語 Red Hat 7.x はデフォルトでは JIS X 0201 の TrueType フォントを持っていないので、日本語フォントプロパティファイル font.properties.jaには JIS X 0201 が定義されていません。この問題を回避するには、TrueType JIS X 0201 フォントをインストールし、適宜 font.properties.ja ファイルを変更します。

• 64 ビットの Itanium Linux プラットフォームでは、drawString メソッドで日本語の文字が正しく表示されない場合があります。バグレポート 4704500 を参照してください。

「インストールガイド Linux 版」の既知の問題の節も参照してください。

Sun ONE Studio 3.0, Community Edition と NetBeans 3.2.1 は、J2SDK v1.4.1 と連携して動作します。ただし、Forte for Java 2.0 と NetBeans 3.2 は、J2SDK v1.4.1 と連携して動作しません。

ツールおよびユーティリティ

次の説明は、このリリースのツールおよびユーティリティに関するものです。

• Javac ツール - 変更点については、「拡張および変更点」に記載されています。

• Javadoc ツール : 次のリストには、まだ未解決の 1.4.1 の主なバグと、バージョンがあがったことにより発生する既知の不具合 (1.3.X では機能しますが、1.4.0 および 1.4.1 では正常に機能しない機能) のすべてを示します。新機能およびバグ修正に関しては、「What's New in Javadoc 1.4.1」(1.4.1/docs/tooldocs/javadoc/whatsnew-1.4.1.html) を参照してください。すべてのバグに関しては、「What Bugs are in Javadoc?」を参照してください。
  • 退行問題 : -link や -linkoffline を使用した外部メソッドへのリンクが生成されない。回避方法は不明。 バグ 4615751

  • 退行問題 :「直列化された形式」へのリンクに (含まれるはずの) クラスへのアンカーが含まれない。 バグ 4521661

  • 退行問題 : クラス / インタフェース間の相互参照が生成されない。 バグ 4628281

  • 退行問題 : @link が -link で設定された外部クラスにリンクされない。 バグ 4652655

  • タグレットで許可されたインラインタグが使用されない。 バグ 4654636

• libsafe ライブラリのバージョン 1.x (Avaya Labs Research から入手可) の制限のために、J2SDK ツールがメッセージ「Invalid initial heap size: -Xms8m」を表示して失敗する場合があります。-Xms オプションを明示的に指定して java アプリケーション起動ツールを使用しても、失敗します。この問題は、libsafe ライブラリの最新リリースであるバージョン 2.0 (http://www.research.avayalabs.com/project/libsafe/ からダウンロード可) で解決されています。

日本語版 Red Hat 7.* には、デフォルトで JIS X 0201 用の TrueType フォントが含まれないため、日本語フォントプロパティファイル font.properties.ja には JIS X 0201 の定義が含まれません。この問題を回避するには、TrueType JIS X 0201 フォントをインストールし、それに合わせて font.properties.ja ファイルを修正してください。

J2SDK 1.4.0 または 1.4.1 により直列化された java.lang.Throwable およびサブクラス (すべての例外を含む) のインスタンスを、Internet Explorer ブラウザが使用する Microsoft Windows JDK 1.1 実装で直列化復元することはできません。この種のオブジェクトを直列化復元しようとすると、ClassNotFoundException がスローされます。この問題は、バグレポート 4634165 に記載されています。

J2SE 1.4.1 では、Solaris 2.6 オペレーティング環境はサポートされません。これに伴い、J2SE 1.4.1 プラットフォームでは、Motif 1.2 もサポートされません。

プロセッサの浮動小数点ユニット (FPU) には通常、特定の浮動小数点イベントでその動作を制御する制御ワードがあります。浮動小数点イベントとは、例えばオーバーフロー (有限値を超える値を生成した場合)、アンダーフロー (小さすぎる値を生成した場合)、ゼロ除算 （例: 1.0/0.0) の場合に起きるイベントです。 Java は正確にこのようなイベントの結果を定義します。 Java は、IEEE 754 浮動小数点規格のデフォルトの戻り値を使用します (例えば、オーバーフローまたはゼロ除算の場合は正の無限大または負の無限大のどちらかを生成する)。 他の言語環境では、異なる結果となる可能性があります (例えば、ゼロ除算の場合、無限大ではなく例外を生成してプログラムを停止する)。 異なる浮動小数点のセマンティクスのプログラムを Java プログラムで呼び出した場合、その呼び出されたプログラムは、自身のセマンティクスを実装するために FPU 制御ワードを変更する可能性があります。しかし、これら呼び出されるプログラムは、FPU 制御ワードを以前の値に戻すようになっていなければなりません。そのようになっていない場合は、外部プログラムの終了後、誤った浮動小数点例外とともに終了してしまう可能性があります。 市販の DLL の中には、呼び出しスレッドに戻る際に、FPU 制御ワードを元に戻さないものがあることが知られています。浮動小数点例外とともに終了してしまう場合は、その原因としてその可能性を考慮する必要があります。

この問題に関する例は、バグ 4644270 を参照してください。