|
Java SE プロジェクトチームは、JDK に貢献してくださったコミュニティーのメンバーの方々に感謝します。
既知のバグと問題
この文書では、次のリストに従って、今回のリリースにおける既知のバグとその回避方法、その他の重要な問題について簡単に説明します。
- OS とハードウェアプラットフォーム
- Linux 使用時の注意
- Solaris 使用時の注意
- Windows 使用時の注意
- Windows Vista 使用時の注意
- 仮想マシン
- HotSpot VM
- コアライブラリ
- セキュリティー
- Java Debugger Wire Protocol
- Java Native Interface
- Java スクリプト
- JAX-WS
- 統合ライブラリ
- JDBC
- ユーザーインタフェース
- Java 2D
- Swing
- AWT
- 配備
- 一般的な配備
- アプレット
- ドキュメント
- サポートされる構成
Linux 使用時の注意
Linux プラットフォーム上でこのリリースを使用する際の注意点は次のとおりです。
- 一部のバージョンの Linux では、/proc ファイルシステムがマウントされていない場合、chroot(3) 環境で Java VM が不安定になることがあります。これは、一部の Linux ライブラリと VM ルーチンが /proc ファイルシステムから情報 (プロセッサ数、スタック境界、メモリー構成) を抽出しようとするためです。これらのルーチンは、特にプロセスがマルチスレッドの場合、不正なデフォルトにフェイルオーバーするかクラッシュすることがあります。
この Linux バグがあるかどうかを検出するには、
getconf _NPROCESSORS_CONFシェルコマンドを chroot(3) 環境で実行します。システム上の正しいプロセッサ数が返されるはずです。返されない場合は、chroot(3) ファイルシステムの内部で Java を実行するために /proc ファイルシステムをマウントする必要があります。Solaris 使用時の注意
Solaris プラットフォーム上でこのリリースを使用する際の注意点は次のとおりです。
- Solaris では、スレッドが特定の I/O 操作を試みる場合のスレッド割り込みが操作の割り込みとなり、Linux または Windows プラットフォームでは無視されるスレッド割り込みに対して
InterruptedIOExceptionがスローされます。スレッド割り込みに対応するこの Solaris 特有の I/O 割り込みは、以前のリリースと同じくデフォルトで有効になっていますが、新しいUseVMInterruptibleIOオプションスイッチで制御できるようになりました。デフォルトでは、以前の動作を維持するためにこのオプションがオンになっています。このオプションは次の方法でオフに切り替えることができます。-XX:-UseVMInterruptibleIOこれにより、スレッド割り込みに対応する Solaris 特有の I/O 割り込みが無効になります。
次の Java SE のメジャーリリースでは、移植性を向上させるために、このオプションはデフォルトでオフに設定される可能性があります。この変更が行われた場合、Solaris 特有の動作を必要に応じて使用できるようオプションは残ります。
詳細は、バグレポート 4385444 を参照してください。
- 個々の制限については、「Hotspot VM」を参照してください。
Windows 使用時の注意
Windows プラットフォーム上でこのリリースを使用する際の注意点は次のとおりです。
- J2SE 5.0 でのスレッド優先順位の退行バグは、J2SE 5.0 の Update 6 と Java SE 6 では修正されています。正しい動作に戻っているため、回避策は不要になりました。
Windows では、デフォルトで、Java スレッド優先順位
MAX_PRIORITYがネイティブの最高優先順位 (THREAD_PRIORITY_TIME_CRITICAL) に対応付けられる代わりに、THREAD_PRIORITY_HIGHESTに対応付けられるようになりました。このような変更が行われたのは、THREAD_PRIORITY_TIME_CRITICALスレッドがシステムスレッドに割り込んで、システムの応答性に影響を及ぼす可能性があるからです。以前の動作 (
THREAD_PRIORITY_TIME_CRITICAL) に戻す必要がある場合は、-XX:ThreadPriorityPolicy=1を設定します。詳細は、バグレポート 5101898 を参照してください。
- カスタムの起動ツールを使用する Java SE 6 アプリケーションは、起動ツールの実行可能ファイルと同じディレクトリに
msvcr71.dllとともにインストールする必要があります。これは、http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_C_Run.2d.Time_Libraries.asp に基づく新しい Windows C ランタイムの配布モデルに従っています。詳細は、バグレポート 6509291 にも記載されています。
- 個々の制限については、「Hotspot VM」も参照してください。
- 個々の制限については、「一般的な配備」も参照してください。
Windows Vista 使用時の注意
Windows Vista プラットフォーム上でこのリリースを使用する際の注意点は次のとおりです。
- Windows Vista には、署名付きアプレットに対してより制限のあるサンドボックスがあります。ほかの Windows OS 上で実行している場合よりもユーザーの特権が少なくなります。
Windows Vista 以外の Windows OS では、署名付きアプレットを実行するとセキュリティー警告のダイアログボックスが表示され、ユーザーはそれに回答する必要があります。「はい」をクリックすると、ユーザーのマシンで実行するための AllPermissions がアプレットに与えられます。このアクセス権には、ローカルディスクのファイルに対する書き込みと削除も含まれます。
Windows Vista OS では、上記のようにはなりません。AllPermissions は、Windows の範囲ではなく Java Applet の範囲に制限されます。IE で実行される処理は整合性レベルが低いため、中/高レベルの整合性のディレクトリに対してファイルの書き込みや削除を行うことはできません。
- 署名付き JNLP アプリケーションは中レベルの整合性でのみ実行できます。AllPermissions を Java Web Start アプリケーションで認めると、そうでない場合には SecurityExceptions のスローによって拒否するような操作を、セキュリティーマネージャーで許可することができます。ユーザーやプロセスがシステムに持つアクセス権を増やすものではありません。
たとえば、通常の (管理者以外の) ユーザーは、自分のホームディレクトリのファイルのみを読み書きできます (ほかのディレクトリが、すべてのユーザーにアクセス権を与えるように特別に作成されている場合を除く)。
- HTTPS 接続におけるユーザーエクスペリエンスの変更
Windows Vista OS には、HTTPS 接続のセキュリティーとユーザーエクスペリエンスの分野でいくつかの新しい動作 (バグレポート 6408329 を参照) が導入されています。これらは次のとおりです。
- HTTPS 証明書
IE7 は、次のような問題のあるデジタル証明書を提示する HTTPS サイトへのナビゲーションをブロックします。
- 証明書が現在の URL のホスト名とは異なるホスト名に発行されている。
- 証明書が信頼できないルートによって発行されている。
- 証明書の期限が切れている。
- 証明書が失効している。
デジタル証明書の問題が見つかると、IE7 はその問題を説明するエラーページを表示します。ユーザーは、証明書エラーにかかわらず、その警告を無視して処理を進めることもできます (証明書が失効していない場合)。ユーザーが証明書のエラーページをクリックスルーすると、アドレスバーが赤くなり、問題を継続的に通知します。
- 混合コンテンツのプロンプト
混合コンテンツのプロンプトと呼ばれる次のようなプロンプトがユーザーに表示されることはなくなりました。
「このページにはセキュリティで保護されている項目と保護されていない項目が含まれています。 保護されていない項目を表示しますか?」IE7 はセキュリティー保護されたコンテンツのみを描画します。ユーザーは、情報バーを使用して、セキュリティー保護されていないコンテンツをブロック解除することもできます。
- 新しいデフォルトプロトコルモード
Windows Vista の IE7 は、デフォルトの HTTPS プロトコル設定を変更し、弱い SSLv2 プロトコルを無効にし、強い TLSv1 プロトコルを有効にしました。
上記の Windows Vista の IE7 の変更によって、アプレットを実行したときの Java plugin の動作が変わります。
- コントロールパネルで JRE の自動ダウンロードが無効
公開された自動ダウンロードバンドルは (すべてのリリースについて書き直しおよび再ステージしないかぎり) Vista 上で実行できないため、自動ダウンロード機能はデフォルトで無効になり、コントロールパネルの詳細タブのエントリが無効になります。
- コントロールパネルでキャッシュ場所の変更ダイアログが無効
キャッシュ場所は整合性の低いディレクトリに設定する必要があるため、キャッシュ場所を変更する機能はコントロールパネルで無効になりました。バグレポート 6422509 を参照してください。
- Java Plug-in 拡張インストーラ機構が、IE で管理者以外のユーザーによる実行で失敗することがある
1.4.2 の Plug-in に追加された拡張インストール機構は、Java 拡張インストーラ (
java -jar <file>を実行) の実行またはネイティブ拡張 (<file>を実行) の実行にRuntime.exec()を使用します。通常、これらのインストーラは jre の lib/ext ディレクトリへのファイルの書き込みなどを行います。これらのプロセスはユーザーが持っているものと同じ制限された権限で実行され、たとえばユーザーが書き込み権限のない場所にファイルを書き込もうとすると失敗します。
この問題は、一般的な用例ではありませんが、拡張を lib/ext にインストールしようとするすべての Java Web Start アプリケーションで起こる可能性があります。
バグレポート 6432317 を参照してください。
- Gamesville- Bottle Rocket アプレットが読み込みに失敗する
この問題は IE7 の新しい Javascript 実装に関連しています。Microsoft のバグ (140684) が提出されており、Microsoft によって調査中です。
- Yahoo-Finance Stock Screener アプレットが読み込みに失敗する
このバグはユーザーエラーによるものです。アプリケーションは IE6 を確認し、IE7 とは互換性のない IE6 より前の動作に戻ります。この変更/制限は Microsoft によって文書化されています。
バグレポート 6421625 を参照してください。
- Vista の IE7 で実行しているアプレットからアイコンをトレイに追加できない
システムトレイにアイコンを追加しようとすると暗黙的に失敗し、例外も発生しません。これは Internet Explorer 7 でセキュリティーが強化された結果です。
バグレポート 6419042 を参照してください。
- Vista の Desktop Window Manager との非互換性により、Windows Vista でハードウェアの高速化に DirectDraw を使用することは、現在デフォルトで無効になっています。
-Dsun.java2d.noddraw=falseプロパティーを使用すると、DirectDraw パイプラインの使用を再度有効にすることができます。ただし、レンダリングアーティファクトとパフォーマンスの問題のため推奨されません。Direct3D パイプラインも有効にするには、上記のフラグと-Dsun.java2d.d3d=trueを組み合わせて使用します。詳細は、バグレポート 6343853 を参照してください。
- Java SE 6 アプリケーション/アプレット (スタンドアロン、Java Plug-in、Java Web Start) は Windows XP 互換モードでの実行をサポートしません。
- Java コントロールパネル: 詳細タブにある「ブラウザのデフォルトの Java」のチェックボックスは、標準ユーザーには機能しません。この問題を回避するには、Java コントロールパネルを管理者として実行する必要があります。
詳細は、バグレポート 6486929 を参照してください。
- Java コントロールパネル: Java コントロールパネルを終了する際に Windows Vista で「プログラム互換性アシスタント」ダイアログボックスが表示される場合があります。その場合は「このコントロール パネルは正常に動作します」を選択することをお勧めします。これにより、次回 Java コントロールパネルを終了する際にこのダイアログは表示されません。
「推奨の設定を使用してコントロール パネルを開きます」を選択すると、Java コントロールパネルが正常に動作しなくなります。この設定を元に戻すには、javacpl.cpl または jpicpl32.cpl を含む次のレジストリエントリを削除する必要があります。
- HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatiblity Assistant\Persisted
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
詳細は、バグレポート 6485081 を参照してください。
- デスクトップフォルダからユーザーディレクトリや Public ディレクトリを選択しようとすると失敗します。次に例を示します。
JFileChooserを Windows Look & Feel で開きます。- 左側のデスクトップボタンをクリックします。
- デスクトップから自分のディレクトリまたは Public ディレクトリに入ってみます。ディレクトリには入ることができません。コンソールに例外はスローされません。
この問題を回避するには、ほかの方法でこれらのディレクトリに入ります。次に例を示します。
c:-> c:/users/ -> c:/users/<user dir> c:-> c:/users/ -> c:/users/Public詳細は、バグレポート 6488081 を参照してください。
JFileChooserをOceanLook & Feel で使用する場合、ユーザーディレクトリおよび Public ディレクトリはデスクトップフォルダで正しく表示されません (「参照」をクリックして「デスクトップ」を選択)。参照コンボボックスからも正しく表示されません。ディレクトリは文字や数字の長い列で表示され、これらの列を選択してもディレクトリに入ることはできません。これらのディレクトリにアクセスするには、上記の 6488081 で記載した回避方法を使用してください。
詳細は、バグレポート 6488082 を参照してください。
- Windows Look & Feel の
JFileChooserには「最近使った項目」ボタンがあります。このボタンをクリックして表示されるフォルダは常に空です。詳細は、バグレポート 6488492 を参照してください。
仮想マシン
HotSpot VM
このリリースの Java HotSpot 仮想マシン (VM) に関連する注意点は次のとおりです。
- 共通言語ランタイムコンパイラオプション (/clr) を指定してコンパイルされた、JNI を使用する Windows ネイティブコードでは、マネージコード内で
jobject、jfieldID、jmethodID、jrawMonitorIDのいずれかの型を使用すると、.NET の TypeLoadException が発生する可能性があります。この .NET 例外を放置していると、Windows システムライブラリkernel32.dll内の例外コード0xe0434f4dとして、Hotspot エラーハンドラにより報告されます。この問題の発生原因については、http://support.microsoft.com/default.aspx?scid=kb;EN-US;871182 を参照してください。この問題を回避するには、上記の型を参照する関数をプリプロセッサ指令
pragma unmanagedでマークします。詳細は、バグレポート 6220093 を参照してください。
- Solaris Hotspot VM
java.library.pathが変更されました。以前のリリースでは、java.library.pathプロパティーが明示的に設定されていない場合、JNI_CreateJavaVMで作成された Solaris Hotspot VM により、プロパティーが不適切に初期化されることがありました。この動作は修正されました。個々の変更内容は次のとおりです。
- データモデル固有の
LD_LIBRARY_PATH_32またはLD_LIBRARY_PATH_64(どちらも設定されていない場合はLD_LIBRARY_PATH) からjava.library.pathを初期化します。- システムの crle(1) 設定が認識されるようになりました。
- 64 ビットの VM で、
java.library.pathに/usr/libではなく/usr/lib/64が追加されるようになりました。
/usr/lib/64の変更を除き、これらの変更はJNI_CreateJavaVMで作成された VM にのみ影響を及ぼします。Java 起動ツールで作成されたアプリケーションには影響はありません。このバグを回避するために不正な
LD_LIBRARY_PATH設定を使用していたアプリケーションがあります。非常にまれなケースですが、ネイティブライブラリの読み込み時に UnsatisfiedLinkErrors を回避するため、これらのアプリケーションの環境を変更する必要が生じる場合があります。この場合は、LD_LIBRARY_PATH設定を修正するか、java.library.pathに必要な値を明示的に設定することをお勧めします。- Solaris x86 では、java を呼び出すシェルがスタックサイズを「unlimited」に設定している場合、VM が失敗します。これは既知の Solaris x86 カーネルバグ (6374692) です。この問題に対処するために Solaris x86 Kernel パッチ (118855) が開発されています。
この問題を回避するには、131359 より大きい有限のスタックサイズを指定します。次に例を示します。
% ulimit -s 131360JNI ユーザーは、JNI 呼び出し機能を呼び出す前に、次のコードをネイティブコードに挿入することで問題を回避できます。
mmap(0, 0x1000, 0, MAP_PRIVATE | MAP_FIXED | MAP_ANON, -1, 0);詳細は、バグレポート 6444959 を参照してください。
- 以前の JDK リリースでは、java コマンド行起動ツールは、オペレーティングシステムで作成された原始スレッドで JVM を呼び出しました。このため、スタックサイズのチューニングやスタック自体にいくつかの制限が課されていました。このリリースでは、JVM はユーザーレベルのスレッドから呼び出され、スタックサイズはユーザーが設定できます。
詳細は、バグレポート 6316197 を参照してください。
- 以前の JDK リリースでは、
Xcheck:jniはそのチェックが厳しく、ほんの小さなエラーで停止しました。このリリースの更新により、これらのエラーは警告としてフラグが付けられ、JVM は継続します。この目的は、デバッグを容易にして潜在的な問題を発見することです。未処理の例外がある場合、ほとんどの JNI メソッドはユーザー JNI アプリケーションから安全に呼び出すことができないことに注意してください。JNI Specification で説明されているように、例外はあらかじめクリアーするか処理する必要があります。
未処理の例外があるときに JNI メソッド呼び出され、JNI メソッドが VM 操作実行中に例外を受け取ると、未処理の例外は破棄され新しい例外がスローされます。
詳細は、バグレポート 6253381 を参照してください。
- このリリースでは、
-Xincgcオプションにより、標準モードではなく増分モードの並行ガベージコレクタが呼び出されます。増分モードの並行ガベージコレクタは、マイナーコレクションの間にスケジュールされたタイムスライスで並行処理を実行します。増分モードの目的は、増分モードでなければ並行処理に使用されるはずのプロセッサに、アプリケーションがアクセスできるようにすることです。このモードはシングルプロセッサプラットフォームで特に有用です。- プロファイルデータの生成に
-Xprofオプションを使用すると、アプリケーションの実行時に深刻なスローダウンが起こる可能性があります。この問題を回避するには、次の VM オプションを使用します。-XX:SuspendRetryCount=5詳細は、バグレポート 6474293 を参照してください。
コアライブラリ
セキュリティー
- 個々の制限については、「Windows Vista」を参照してください。
Java Debugger Wire Protocol
MONITOR_WAITイベントとMONITOR_WAITEDイベントのlocationフィールドの仕様説明が間違っています。両方においてlocationフィールドは「競合するモニターの入る位置」と定義されています。
MONITOR_WAITイベントについては、次のようになるべきです。location 待機が発生する場所
MONITOR_WAITEDイベントについては、次のようになるべきです。location 待機が発生した場所Java Native Interface (JNI)
- x86 および x64 プラットフォームでは、JNI ネイティブライブラリで MXCSR レジスタに変更を加える場合、このレジスタを callee-save レジスタとして扱う必要があります。x86 ネイティブ ABI は、MXCSR が caller-save か callee-save かを指定しません。しかし、Java SE 6 の JNI は、よりよいパフォーマンスを実現するため、MXCSR を callee-save として扱います。
この処理がアプリケーションで許可されない場合は、
-XX:+RestoreMXCSROnJNICallsVM オプションを指定して、強制的に古い caller-save の MXCSR の動作を採用します。Java スクリプト
- Java SE 6 には、javax.script API (JSR 223) と、JavaScript エンジンのリファレンス実装に基づいた Rhino (Rhino) が含まれています。
Rhino バージョン 1.6R2 の大部分が含まれています (バグ 6330900 を参照)。ただし、フットプリントサイズの問題により、いくつかのコンポーネントは含まれていません。これらは、クラス生成ライブラリまたは XMLBeans ライブラリに依存するコンポーネントです。これらは次のとおりです。
- スクリプトから Java バイトコードへのコンパイルの機能 (オプティマイザ) は含まれていません。この機能は、クラス生成ライブラリに依存します。この機能を削除すると、JavaScript は常にインタプリタ処理されることになります。オプティマイザは透過的なので、この機能を削除してもスクリプトの実行に影響はありません。
Rhino には、インタプリタモードでのみ機能する試験的継続サポートがあります。常にインタプリタモードを使用するので、JavaScript の継続は設定 (最適化レベルを -1 に設定するなどの設定) なしですぐに機能します。
- Rhino の JavaAdapter が削除されました。JavaAdapter は、スクリプトによる Java クラスの拡張やスクリプトによる Java インタフェースの実装を可能にする機能です。この機能も、クラス生成ライブラリを必要とします。この機能は、Sun 独自の JavaAdapter 実装で置き換えられました。Sun の実装では、1 つの JavaScript オブジェクトで、Java インタフェースを 1 つだけ実装できます。次の例は、想定したとおりに機能します。
var v = new java.lang.Runnable() { run: function() { print('hello'); } } v.run();ほとんどの場合、JavaAdapter は Java anonymizer クラスに似た構文で単一のインタフェースを実装するために使用されます。JavaAdapter が Java クラスの拡張や複数のインタフェースの実装に使用されることは、めったにありません。
- E4X (ECMAScript for XML - ECMA Standard E4X) が削除されました。JavaScript コード内で XML リテラルを使用しようとすると、構文エラーが発生します。この機能は、XMLBeans ライブラリに依存します。
- Rhino コマンド行ツール (シェルを含む) は含まれていません。代わりに、jrunscript ユーティリティーを追加しました (JDK のみ)。これは、スクリプト言語に依存しないコマンド行スクリプトシェルで、デフォルトの言語は JavaScript になります。
JAX-WS
wsgen -keepフラグは、生成された Java ソースファイルを保存するために設計されています。このスイッチが指定されていない場合、wsgenはクラスのみを生成する必要があり、Java ソースファイルを保存しません。
現時点で wsgen にはバグがあります。コマンド行に
-keepがあるかないかにかかわらず、wsgenは常に Java ソースファイルを生成します。詳細は、バグレポート 6442344 を参照してください。
wsgenは、デバッグ情報を含むクラスで失敗する可能性があります。 場合によってwsgenは、デバッグ情報を含めるようにコンパイルしたクラスと一緒に動作すると失敗します。Web サービスでSOAPBinding.Style.Documentを使用していて、parameterStyleがSOAPBinding.ParameterStyle.WRAPPEDであり、WebMethodのいずれかがjavax.xml.ws.Holder<T>をWebParamとして使用していると、wsgen が不正なラッパークラスを生成し、コンパイルが失敗します。 この問題を回避するには、変数名のデバッグ情報を含めないように再コンパイルし、javacのオプションに-gではなく-g:lines,sourceを使用します。このオプションの詳細は、the javac options page を参照してください。 この問題の根本的な原因については、バグレポート 6468404 を参照してください。
統合ライブラリ
Java Database Connectivity (JDBC)
- J2SE 5.0 での退行により、実行時にしか検出されない
java.sql.Timestamp.compareToのバイナリ互換性の問題が発生しました。 このバグは、Java SE 6 の Beta2 と J2SE 5.0 の Update7 (5.0u7) で修正されています。
詳細は、バグレポート 5103041 を参照してください。
ユーザーインタフェース
2D
- 個々の制限については、「Windows Vista」を参照してください。
- ストロークと塗りつぶしの操作の実装が変更されました。これらの変更の目的は、特に曲線形状の品質を全体的に向上させることと、ストロークされた形状とその塗りつぶされた形状の間の整合性を向上させることです。 場合によっては、今まで影響のあったピクセルに影響がなくなったり、今まで影響のなかったピクセルに影響が出たりします。後者の動作変更により、塗りつぶしの範囲が拡張されることがあるため、黒丸やチェックマークなどの非常に小さな形状がコンポーネントに密接に囲まれている場合に、塗りつぶしがほかのピクセルを拡張してコンポーネントの境界と重なると、顕著な変化が見られる可能性があります。 これは、次のコードを使用すると回避できる場合があります。以前の動作に近い結果を生成するコードです。
graphics2d.setRenderingHint( RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE);あるいは、収まるように形状を調整します。
Swing
- 個々の制限については、「Windows Vista」を参照してください。
- 以前の JDK では、不正な値である
JFrame.EXIT_ON_CLOSEをjavax.swing.JDialogのsetDefaultCloseOperation(int operation)メソッドに渡すことができました。JDialogは exit-on-close 動作をサポートせず、暗黙のうちにDO_NOTHING_ON_CLOSEを行います。Java SE 6 では、不正な値を
JDialog.setDefaultCloseOperation(int operation)に渡すと実行時にIllegalArgumentExceptionが発生します。詳細は、バグレポート 5109681 を参照してください。
- 次のパッケージに含まれているクラスがコードで使用されている場合、javac でコードをコンパイルする際に、Sun の所有権に関する警告が間違って表示されます。
- com.sun.java.swing.plaf.windows
- com.sun.java.swing.plaf.motif
- com.sun.java.swing.plaf.gtk
この警告の目的は、専有 API の使用について開発者に警告することです。ただし、上記のパッケージに関しては表示されるべきではありません。したがって、これらのパッケージに関する限りは無意味な警告です。
詳細は、バグレポート 6476749 を参照してください。
AWT
- Solaris および Linux では、現在の実装では JWindow がほかのすべてのウィンドウの上に表示されます。この問題を回避するには、非装飾フレームを使用します。
詳細は、バグレポート 5070056 を参照してください。
- 合成的な状況 (トップレベルの表示と破棄が繰り返されるなど) では、JVM がクラッシュする場合があります。
詳細は、バグレポート 6387273 を参照してください。
配備
一般的な配備
- Solaris および Linux システムでは、Java コントロールパネルでプロキシが「ブラウザの設定を使用」に設定されている場合、Java Plug-in および Java Web Start はデフォルトブラウザを認識しません。 企業のファイアウォールの内側でインターネットに接続するには、ブラウザのプロキシ設定が必要です。JDK6 ではプロキシ設定は Firefox、Mozilla、Netscape の順で判定されます。そのため、Firefox のプロキシ設定が不正な場合は Java Web Start および Java Plug-in もインターネットに接続できません。Java Plug-in アプレットまたは Java Web Start アプリケーションを実行した場合、結果は「unable to connect to URL」例外になります。 この問題を回避するには、Firefox のプロキシ設定を正しく行うか、Java コントロールパネルを使用してプロキシ設定を手動で行います。
詳細は、バグレポート 6478804 を参照してください。
- JDK または JRE の Linux x64 バンドルをインストールする場合、次のようなエラーメッセージが表示される可能性があります。
cp:開始できませんこのようなメッセージは無視してかまいません。Java は正しくインストールされ、機能しています。: そのようなファイルやディレクトリはありません 詳細は、バグレポート 6438881 を参照してください。
アプレット
- Internet Explorer で表示されるアプレットでシャットダウンフックが動作しません。
詳細は、バグレポート 6434129 を参照してください。
- このトピックの詳細と背景については、「Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer」を参照してください。
- アプレットの JAR リソースの URL にクエリー文字列が含まれている場合に、Web サーバーから返された HTTP ヘッダーにリソースをキャッシュすべきでないと指定されているとき (つまり、cache-control: no-store の場合、あるいは last-modified と expiration の両方が設定されていない場合) は、リソースは Java Plug-in でキャッシュされません。
バグ 6506479 のため、Java Plug-in がリソースを一時的な場所にダウンロードする際に URL 内のクエリー部分が使用されず、その結果 JAR リソースが正しくダウンロードされないことがあります。
この問題を回避するには、JAR リソースの URL にクエリー文字列が含まれている場合は、アプレットの JAR リソースをキャッシュできるように Web サーバーから適切なヘッダーが返されることを確認してください。
詳細は、バグレポート 6506479 を参照してください。
ドキュメント
サポートされる構成
- 「サポートされているロケール」ドキュメントの「サポートされる書記法」表の上付き (5) に、特定のエンコーディングで Sun Java Desktop System Release 3 がサポートされると記述されています。これは誤りです。Linux 版 Sun Java Desktop System で JDK 6 はサポートされません。
|
| ||||||||||||