本書および本書で紹介する製品をご使用になる前に、特記事項に記載されている情報をお読みください。
本書は、IBM 32-bit SDK and Runtime Environment for Windows, Java Technology Edition, Version 6、および新しい版で明記されていない限り、以降のすべてのリリース、モディフィケーション、および Service Refresh に適用されます。
(C) Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
IBM 発行のマニュアルに関する情報のページ
http://www.ibm.com/jp/manuals/
こちらから、日本語版および英語版のオンライン・ライブラリーをご利用いただけます。 また、マニュアルに関するご意見やご感想を、上記ページよりお送りください。今後の参考にさせていただきます。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。
|
(C) Copyright IBM Japan 2007
本書には、IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) Technology Edition, Version 6 の概説と、 Sun の実装と対比した IBM の実装の相違点に関する具体的な情報が記載されています。
本書は、Sun の Web サイト (http://java.sun.com) の詳細な資料と一緒にお読みください。
SDK および Runtime Environment は、次の製品でサポートされています。
以下の仮想化環境がサポートされています。
IPv6 は Windows XP および Windows Server 2003 でのみサポートされています。
IBM Virtual Machine for Java について詳しくは、「Diagnostics Guide (英語)」を参照してください。
このユーザー・ガイドは、リリースの一部であり、その特定のリリースにのみ適用可能です。使用しているリリースに適切なユーザー・ガイドであることを確認してください。
用語「Runtime Environment」と「Java 仮想マシン」は、本書では同じ意味で使用されています。
|本書のこのバージョンでの技術的な変更は、小さな変更や明らかな変更を除き、インフォメーション・センターでは青色の山形文字で示され、HTML やカラー印刷コピーでは、変更箇所の左側に赤の縦線が表示され、PDF では変更箇所の左側に縦線が表示されています。
このプログラム・コードは、航空機オンライン制御、航空管制、航空ナビゲーション、航空通信などを含む (がこれに制限されない) リアルタイム・アプリケーション、および核施設の設計、建設、稼働、または保守における使用を想定しておらず、また、そのような使用のために設計されたものでもありません。
IBM SDK は、Java 6 Core Application Program Interface (API) に準拠したアプレットやアプリケーションを作成して実行するための開発環境です。
SDK には、Java アプリケーションの実行のみを可能にする、Runtime Environment for Windows が 含まれています。SDK をインストールしている場合には、Runtime Environment が組み込まれています。
Runtime Environment には、Java 仮想マシンと、クラス・ファイルなどのサポート・ファイルが含まれています。Runtime Environment には、SDK にあるクラスのサブセットのみが含まれているため、実行時に Javaプログラムをサポートすることはできますが、Java プログラムのコンパイルはできません。Runtime Environment for Windows には、appletviewer.exe または Java コンパイラー (javac.exe) などの開発ツールや、開発システム専用のクラスは一切含まれていません。
さらに、Java Communications のアプリケーション・プログラミング・インターフェース (API) パッケージ が Runtime Environment for Windows と一緒に使用するために提供されています。 これについては、Java Communications API (JavaComm) の使用を参照してください。
以前のバージョンの SDK で稼働したアプレットまたはアプリケーションは、一般に、IBM 32-bit SDK for Windows, v6 でも正しく動作します。 このリリースでコンパイルしたクラスについて、前のリリースでの動作は保証できません。
IBM 32-bit SDK for Windows v6 は、Microsoft Visual Studio .NET 2003 を使用して作成されました。
リリース間での互換性について詳しくは、以下の Sun の Web サイトを参照してください。
|http://java.sun.com/javase/6/webnotes/compatibility.html
http://java.sun.com/j2se/5.0/compatibility.html
http://java.sun.com/j2se/1.4/compatibility.html
http://java.sun.com/j2se/1.3/compatibility.html
他の製品 (IBM WebSphere(R) Application Server など) の一部として SDK を使用していて、以前のレベルの SDK (v5.0 など) からアップグレードする場合、直列化されたクラスに互換性がないことがあります。ただし、クラスは Service Refresh 間で互換性を持ちます。
バージョン 5.0 から、IBM Runtime Environment for Windows には、新しいバージョンの IBM Virtual Machine for Java と Just-In-Time (JIT) コンパイラーが含まれています。
以前の IBM Runtime Environment からマイグレーションする場合は、以下のことに注意してください。
SDK には、いくつかの開発ツールと Java Runtime Environment (JRE) が含まれています。この節では、SDK ツールと Runtime Environment のコンテンツについて説明します。
全体が Java で書かれたアプリケーションでは、IBM SDK のディレクトリー構造 (あるいは、それらのディレクトリー内のファイル) に対する依存関係が皆無であるべきです。SDK のディレクトリー構造 (あるいは、それらのディレクトリー内のファイル) に対する依存関係があると、 アプリケーションの移植性の問題が生じる場合があります。 Java Native Interface (JNI) アプリケーションには、軽度の依存関係ができる可能性があります。
この SDK for Windows に組み込まれているドキュメンテーションは、ユーザー・ガイド、Javadoc、および付随するライセンス、著作権ファイル、javadoc、および demo ディレクトリーのみです。Sun の Web サイト (http://java.sun.com) にアクセスして Sun のソフトウェア・ドキュメンテーションを表示するか、あるいは、この Web サイトから Sun の ソフトウェア・ドキュメンテーション・パッケージをダウンロードすることができます。
標準的な Runtime Environment と一緒に使用できるクラスおよびツールのリストです。
標準 SDK に含まれているツールと参照情報のリストです。
ライセンス・ファイル C:¥Program Files¥IBM¥Java60¥docs\content\<locale>\LA_<locale>には、SDK for Windows ソフトウェアのご使用条件が含まれています (<locale> は使用するロケールの名前です。例えば en)。ご使用条件を 表示あるいは印刷するには、Web ブラウザーでこのファイルをオープンしてください。
SDK のインストールにはインストール・ウィザードまたは圧縮ファイルを使用します。SDK の構成には環境変数、コマンド行オプション、およびプロパティー・ファイルを使用します。
SDK または Runtime Environment パッケージをインストールするには、該当するインストール・パッケージをダウンロードします。すべてのパッケージを同一ディレクトリーにダウンロードしており、一時ディレクトリーに十分なスペースがあることを確認します。
パッケージとパッケージ内のファイルの名前のリストについてはパッケージのインストールを参照してください。パッケージのファイル名は変更しないでください。
インストールを開始する前に、インストール中に使用される C:¥WINDOWS¥TEMP ディレクトリーに十分なスペースがあることを確認してください。インストール中に TEMP ディレクトリーに必要な一時スペースの量を次に示します。
十分な一時スペースがないと、インストール・プログラムはエラーを生成し、インストールを強制終了します。十分な一時スペースがあるにもかかわらずこのメッセージが表示される場合は、インストールするパッケージが完全にダウンロードされているかどうかを確認してください。これを確認するには、ダウンロードしたパッケージのファイル・サイズと、パッケージのダウンロード元 Web ページに示されているファイル・サイズを比較します。
個別にインストールできるパッケージは、 SDK、Runtime Environment、 Javacomm、資料、デモなど、多数あります。
インストールできるパッケージは以下のとおりです。
その他のパッケージは、圧縮ファイルとして提供されます。
SDK または Runtime Environment を圧縮パッケージからインストールする場合、Web Start または Java Plug-in は使用できません。また、コントロール・パネルに組み込まれる「更新」タブは機能しません。
SDK または JRE を 1 つのクライアントにインストールするには、手動インストールを使用します。
Runtime Environment は、デフォルトでは C:¥Program Files¥IBM¥Java60¥jre ディレクトリーにインストールされます。
SDK インストール・パッケージをダウンロードした場合は、インストールするコンポーネントを選択できます。
インストール・ウィザードで、次のオプションが表示されます。
Windows Vista では、インストール言語の選択後の処理が遅れることがあります。
インストールが失敗し、エラー・メッセージ「変換適用中にエラーが発生しました (Error applying transform)」が示される場合は、Windows インストーラー構成情報が壊れています。このエラーを修正するには、http://support.microsoft.com/kb/290301 の Windows Installer Cleanup ユーティリティーを使用して、破損した Windows インストーラー構成情報を除去します。
Runtime Environment を (SDK インストール・パッケージの一部として、あるいは Runtime Environment インストール・パッケージから) インストールするときに、Runtime Environment をシステム Java 仮想マシン (JVM) としてインストールするかどうかを決定するよう求められます。システム JVM としてインストールする場合は、インストール・プログラムにより java.exe、javacpl.cpl、javaws.exe、および javaw.exe ランチャーが Windows システム・ディレクトリーにコピーされます。
java.exe または javaw.exe が既に Windows システム・ディレクトリーにある場合は、既存のバージョンを新規バージョンで上書きするかどうかを尋ねるプロンプトが出されます。これらのファイルを Windows システム・ディレクトリーにインストールすると、この Runtime Environment がシステムのデフォルト JVM になります。また、「現在のバージョン」のレジストリー・キーがこのインストールに合わせて設定されます。
SDK または JRE を複数のクライアントにインストールするには自動インストールを使用します。
自動インストールを作成するには、まず手動インストールを実行し、インストール中の選択内容を記録する応答ファイル (setup.iss) を作成します。作成する応答ファイルの内容は、このファイルを使用する予定のすべてのコンピューターで正しいものでなければなりません。必要に応じて、構成が異なるコンピューターにパッケージをインストールするときに使用する複数の応答ファイルを作成します。
インストール実行中に応答ファイルを作成するには、コマンド・プロンプトから次のように入力します。
ibm-java-sdk-60-win-i386 /r
または
ibm-java-jre-60-win-i386 /r
ご使用の Windows 製品に応じて、応答ファイル (setup.iss) が C:¥Windows または C:¥Winnt のいずれかのディレクトリーに作成されます。
対話式インストールの実行中に次のメッセージが表示されることがあります。
別の Java Runtime Environment が現在 System JVM としてインストールされています。 このバージョンを上書きする場合は「はい」を選択し、このインストールを終了する場合は 「いいえ」を選択してください。 (Select Yes to overwrite this version or No to exit this installation.)
このメッセージが表示されたら、「いいえ」を選択してインストールを終了します。Windows のシステム・ディレクトリーに移動し、次の 2 つのファイルを削除します。
ファイルを削除したら、このセクションの冒頭に示されているコマンドを使用して対話式インストールをもう一度実行します。
自動インストールを実行するシステムの C:¥Windows ディレクトリーに setup.iss 応答ファイルをコピーします。ファイルをコピーしたら、コマンド・プロンプトから次のように入力します。
ibm-java-sdk-60-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log ibm-java-jre-60-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log
インストールが正常に完了すると、ログ・ファイルに ResultCode=0 というストリングが出力されます。 インストールが失敗すると、ログ・ファイルに 0 以外の結果コードが出力されます。
IBM Accessibility Bridge がインストールされますが、デフォルトでは使用不可に設定されています。IBM Accessibility Bridge を使用可能にするには、Accessibility.properties ファイルの assistive_technologies 項目のコメントを外します。
Accessibility.properties ファイルは jre/lib ディレクトリーに格納されています。次のに示す行の先頭から # を削除します。
#assistive_technologies=JawBridge
次に示す Web サイトに、アクセス支援ユーティリティーの詳しい情報があります。
http://java.sun.com/products/jfc/accessibility.html
Java 支援技術をサポートしていない Java アプリケーションの (特にネットワーク・リンク経由での) JVM ロード・パフォーマンスを改善するため、 Java Accessibility サポートを使用不可にできます。Java Accessibility サポートを使用不可にするには、JAVA_ASSISTIVE 環境変数を OFF に設定します。
この環境変数が OFF に設定されていると、Accessibility.properties ファイルで JawBridge などの支援技術が有効に設定されている場合でも、これらの支援技術を使用できません。
Windows では、1 つのプロセスに、ANSI (または Windows) と OEM (または DOS) という 2 つのコード・ページがあります。console.encoding システム・プロパティーが設定されていない場合は、javaw コマンドでは常に ANSI コード・ページが使用されます。
通常、コマンド・ウィンドウでは OEM コード・ページが使用されます。Java コンソール出力では、Java を開始したコマンド・ウィンドウのコード・ページが使用されます。ただし、javaw コマンドでは常に ANSI コード・ページが使用されます。コンソール出力に使用するコード・ページを指定するには、java またはjavaw ランチャーの -Dconsole.encoding オプションを使用します。例えば、-Dconsole.encoding=Cp1252 と指定すると、すべてのコンソール出力で Windows ANSI Latin1 コード・ページ (1252) が使用されます。
PATH 環境変数を変更すると、ご使用のパスにある既存の Java ランチャーがすべてオーバーライドされます。
PATH 環境変数により、Windows は、どの現行ディレクトリーからでも javac、java、および javadoc などのプログラムおよびユーティリティーを見つけられるようになります。ご使用の PATH の現行値を表示するには、コマンド・プロンプトで次のように入力します。
echo %PATH%
ご使用のパスに Java ランチャーを追加するには、次のようにします。
パスを設定した後は、任意のディレクトリーからコマンド・プロンプトでツールの名前を入力することにより、ツールを実行できます。例えば、ファイル Myfile.Java をコンパイルするには、コマンド・プロンプトで、以下のように入力します。
javac Myfile.Java
クラスパスにより、SDK ツール (java、javac、および javadoc など) は Java クラス・ライブラリーがある場所がわかります。
以下に該当する場合のみ、クラスパスを明示的に設定する必要があります。
CLASSPATH 環境変数の現行値を表示するには、コマンド・プロンプトで次のコマンドを入力します。
echo %CLASSPATH%
別にインストール済みの他のバージョンも含めて、 異なるランタイム環境を使用する複数のアプリケーションを作成し実行する場合、CLASSPATH および PATH をアプリケーションごとに明示的に設定する必要があります。複数アプリケーションを 同時に実行し、異なるランタイム環境を使用する場合、それぞれのアプリケーションが固有のコマンド・プロンプトで実行される必要があります。
SDK または Runtime Environment をアンインストールするには、Windows の「プログラムの追加と削除」ユーティリティーを使用します。
SDK をアンインストールするには、自動インストールまたは手動インストールのどちらでインストールを実行した場合でも、次の手順に従います。
この手順では、インストーラーを使用してインストールされたすべてのパッケージが削除されます。Java Communications API パッケージ (Java Communications API のアンインストールを参照) や、圧縮パッケージから解凍した追加ファイルは削除されません。
SDK またはRuntime Environment をアンインストールするために必要な権限がない場合は、「Error1325.launchpad は有効な短ファイル名ではありません。」が表示されます。SDK または Runtime Environment をアンインストールするには、正しい権限を復元します。
IBM 32-bit SDK for Windows, v6 と V1.3.1 およびそれ以前のバージョンを複数インストールして維持している場合、v6 がシステムにインストールされている状態で、古いバージョンをアンインストールすると、V1.3.1 アンインストーラーにより、v6 バージョンに必要な次のレジストリー・キーとすべてのサブキーが削除されます。このため、インストールされている v6 が破損します。
したがって、V1.3.1 をアンインストールした場合は、その後に v6 を再インストールしてください。このアンインストーラーの制限は、V1.4.0 およびそれ以降のリリースでは修正されています。
Java アプリケーションは、java ランチャーまたは JNI を使用して開始できます。設定値は、コマンド行引数、環境変数、およびプロパティー・ファイルを使用して Java アプリケーションに受け渡されます。
java および javaw コマンドの簡単な概要です。
java および javaw ツールは、Java Runtime Environment を開始し、指定されたクラスをロードすることによって、Java アプリケーションを起動します。
javaw コマンドは、javaw には関連するコンソール・ウィンドウがないことを除いて、java と同一です。 コマンド・プロンプト・ウィンドウを表示したくない場合には javaw を使用してください。javaw ランチャーは、起動に失敗した場合に、エラー情報を含むダイアログ・ボックスを表示します。
JVM は、初期クラス (および使用されるその他のクラス) を、ブートストラップ・クラスパス、 インストールされた拡張機能、ユーザー・クラスパスの 3 カ所で検索します。クラス名または JAR ファイル名の後に指定する引数が、main 関数に渡されます。
java および javaw コマンドの構文は次のとおりです。
java [ options ] <class> [ arguments ... ] java [ options ] -jar <file.jar> [ arguments ... ] javaw [ options ] <class> [ arguments ... ] javaw [ options ] -jar <file.jar> [ arguments ... ]
ご使用の Java インストール済み環境の IBM ビルドおよびバージョン番号は、-version オプションを使用して取得します。|-Xjarversion オプションを使用すると、クラスパスにあるすべての jar ファイルのバージョン情報も取得できます。
java -version以下に類似した情報が表示されます。
java version "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070227_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT enabled) J9VM - 20070226_11758_lHdSMR JIT - dev_20070215_1800 GC - 20070208_AA)ビルド日とバージョンが変更されます。
|
| また、以下のコマンドを入力すると、クラスパス、ブート・クラスパス、および拡張ディレクトリーにあるすべての利用可能な jar ファイルのバージョン情報を表示することもできます。
java -Xjarversion|
以下に類似した情報が表示されます。
|... |C:¥Program Files¥IBM¥Java60¥jre\lib\ext\ibmpkcs11impl.jar VERSION: 1.0 build_20070125 |C:¥Program Files¥IBM¥Java60¥jre\lib\ext\dtfjview.jar |C:¥Program Files¥IBM¥Java60¥jre\lib\ext\xmlencfw.jar VERSION: 1.00, 20061011 LEVEL: -20061011 | |...|
利用可能な情報はそれぞれ jar ファイルごとに異なり、jar ファイルのマニフェストにある Implementation-Version および Build-Level プロパティーから取得されます。
オプション・ファイルや環境変数を使用して、コマンド行に Java オプションおよびシステム・プロパティーを指定できます。
Java オプションを指定するこれらのメソッドは、優先順位の順序でリストされます。
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
set IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"
コマンド行では、右端のオプションが左端のオプションより優先されます。 例えば、
java -Xint -Xjit myClass
というオプションを指定したとします。 この場合、-Xjit オプションが優先されます。
標準オプションの定義
java および javaw ランチャー では、現行ロケールの文字セット内の任意の文字を含む引数およびクラス名が受け入れられます。また、Java エスケープ・シーケンスを使用して、クラス名と引数に任意の Unicode 文字を指定することもできます。
これを行うには、-Xargencoding コマンド行オプションを使用します。
例えば、「HelloWorld」というクラスを 2 つの大文字について Unicode エンコード方式を使用して指定する場合、 次のコマンドを使用します。
java -Xargencoding '¥u0048ello¥u0057orld'
java および javaw コマンドは、翻訳されたメッセージを示します。これらのメッセージは、Java が稼働しているロケールに基づいて異なります。java が戻す、エラーの詳細説明やその他のデバッグ情報は、英語で表示されます。
Java クラスまたは JAR ファイルを Windows エクスプローラから自動的に開始するように設定するには、Windows エクスプローラの「ツール」 -> 「フォルダ オプション」 -> 「ファイルの種類」オプションを使用します。
あるいは、コマンド・プロンプトから次のように入力します。
assoc .class=javaclass ftype javaclass=C:¥Program Files¥IBM¥Java60¥jre¥bin¥java.exe''%l''%*'
Sun では、スクリーン・リーダー、Java アプリケーションにおける Java Accessibility サポートへのアクセスなど、ネイティブ Windows 支援テクノロジーを使用するための、Java Access Bridge を提供しています。これらのネイティブ Windows 支援テクノロジーは、Java Access Bridge の呼び出しをサポートする必要があります。
Sun から入手できる Java Access Bridge には、5 つのファイル (access-bridge.jar、jaccess.jar、accessibility.properties、JavaAccessBridge.dll および WindowsAccessBridge.dll) を正しいディレクトリーに配置するインストーラーが組み込まれています。IBM は、JawBridge との使用に適切なディレクトリーで jaccess.jar のコピーを出荷します。
Swing アプリケーションで Windows 2000 Magnifier が機能するように IBM Accessibility Bridge (JawBridge) が既に使用可能になっていて、 Java Access Bridge と同時に JawBridge を使用可能にしたい場合は、 accessibility.properties ファイル内の行を、以下のように編集してください。
assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge
両方のブリッジを非アクティブにするには、先頭に # を挿入して、 その行をコメント化してください。 次の Web サイトで、Java Access Bridge のダウンロード方法が分かります。
http://java.sun.com/products/jfc/accessibility.html
IBM Just-In-Time (JIT) コンパイラーは、Java アプリケーションやアプレットで実行中に頻繁に使用される バイトコード・シーケンスのマシン・コードを動的に生成します。JIT v6 コンパイラーは、コンパイラーの研究によって新しい最適化を実現し、 前のバージョンの JIT に実装されていた最適化を改良して、ハードウェアをより大きく活用しています。
IBM SDK および Runtime Environment には共に JIT が含まれており、ユーザー・アプリケーションや SDK ツールでも、 デフォルトで使用可能に設定されています。通常、明示的に JIT を起動する必要はありません。Java バイトコードからマシン・コードへのコンパイルは、透過的に行われます。 JIT を使用不可に設定すると、問題を切り分けるのに役立ちます。Java アプリケーションまたはアプレットを実行中に問題が発生した場合には、問題を切り分けるために JIT を使用不可にすることができます。JIT を使用不可にするのは、一時的な手段のみにしてください。JIT は、パフォーマンスを最適化するために必要です。
JIT についての詳細は、「Diagnostics Guide (英語)」を参照してください。
JIT はいくつかの異なる方法で使用不可に設定できます。どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。
JIT をオフにすることは、Java アプリケーションをデバッグするときの問題の切り分けに役立つ、一時的な手段です。
set JAVA_COMPILER=NONEまた、グラフィカル・ユーザー・インターフェースを使用して、JAVA_COMPILER を 恒久的に設定することもできます。 「コントロール パネル」を開いて「システム」を選択し、「詳細」タブで「環境変数」を選択します。
java -Djava.compiler=NONE <class>
java -Xint <class>
デフォルトでは JIT は使用可能になっています。JIT は、以下のいくつかの異なる方法で明示的に使用可能にできます。どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。
set JAVA_COMPILER=jitcまた、グラフィカル・ユーザー・インターフェースを使用して、JAVA_COMPILER を 恒久的に設定することもできます。 「コントロール パネル」を開いて「システム」を選択し、「詳細」タブで「環境変数」を選択します。 JAVA_COMPILER 環境変数が空ストリングの場合、JIT は使用不可のままになります。環境変数を使用不可に設定するには、コマンド・プロンプトで以下を入力します。
set JAVA_COMPILER=
java -Djava.compiler=jitc <class>
java -Xjit <class>
JIT の状況は -version オプションを使用して判別できます。
java ランチャーを -version オプションで実行します。 コマンド・プロンプトで、次のように入力します。
java -version
JIT が使用できない場合には、以下の内容のメッセージが表示されます。
(JIT disabled)
JIT が使用できる場合には、以下の内容のメッセージが表示されます。
(JIT enabled)
JIT に付いての詳細は、「Diagnostics Guide (英語)」を参照してください。
ガーベッジ・コレクターは、Java が使用するメモリーおよび JVM 内で稼働するアプリケーションが使用するメモリーを管理します。
ガーベッジ・コレクターはストレージの要求を受け取ると、ヒープ内の未使用メモリーを「割り振り」のプロセスに引き当てます。また、ガーベッジ・コレクターは、もはや参照されていないメモリー領域を確認し、それらを再利用のために 解放します。これが「コレクション」です。
コレクション・フェーズは、メモリーの割り振り障害がトリガーとなって起動されます。割り振り障害は、 ストレージ要求に対してスペースが残っていない場合に発生するか、または、明示的な System.gc() 呼び出しによっても 引き起こされます。
ガーベッジ・コレクションは、アプリケーションのパフォーマンスに大きく影響するので、IBM 仮想マシンは、ガーベッジ・コレクション実行の方法を最適化するためにさまざまな メソッドを提供して、アプリケーションへの影響を削減するようにしています。
ガーベッジ・コレクションに関する詳細情報は、「Diagnostics Guide (英語)」を参照してください。
-Xgcpolicy オプションは、ガーベッジ・コレクターの振る舞いを制御します。これは、アプリケーションおよびシステム全体のスループットと ガーベッジ・コレクションに起因する休止時間とのトレードオフを図ります。
このオプションのフォーマットと値は次のとおりです。
アプリケーションがオブジェクトを作成しようとして、その要求がヒープ内の使用可能スペースの理由ですぐに実現しない場合に、ガーベッジ・コレクターは、参照されていないオブジェクト (ガーベッジ) を 識別してそれらを削除し、ヒープの状態を、即時および後続の割り振り要求にすぐに応じられる状態に 戻す必要があります。
そうしたガーベッジ・コレクションの繰り返しにより、アプリケーション・コードの実行時に 予期しない休止が時々起こることがあります。アプリケーションは大きく複雑になってきており、 ヒープもそれに応じて大規模になっているので、 このガーベッジ・コレクション休止時間は長さも重要度も増す傾向にあります。
デフォルトの ガーベッジ・コレクション値の -Xgcpolicy:optthruput では、 非常に高いスループットがアプリケーションにもたらされますが、 こうした一時休止 (ヒープ・サイズとガーベッジの質により数ミリ秒からかなりの秒数まであり得る) が 代償になっています。
JVM では、並行ガーベッジ・コレクションと世代別ガーベッジ・コレクションという 2 つの手法を使用して休止時間を削減します。
-Xgcpolicy:optavgpause コマンド行オプションは、並行ガーベッジ・コレクションの 使用を要求し、ガーベッジ・コレクションの一時休止にあてられる時間を大幅に削減します。 並行ガーベッジ・コレクション (GC) は、一部のガーベッジ・コレクション・アクティビティーを 通常のプログラム実行と並行して行うことにより、ヒープのコレクションが原因で起きる中断を最小限に して、一時休止時間の削減を図ります。 また、-Xgcpolicy:optavgpause オプションは、ヒープ・サイズの増加が ガーベッジ・コレクション休止の長さに与える影響を制限します。 -Xgcpolicy:optavgpause オプションは、大容量のヒープを抱える構成の場合に 非常に有効です。 休止時間を削減することによって、アプリケーションのスループットがある程度縮小される場合があります。
並行ガーベッジ・コレクション時に、比較的長く存続していて収集できないオブジェクトの識別に かなりの時間が無駄に使われています。ガーベッジ・コレクションがリサイクル可能性の最も高いオブジェクトのみに集中すれば、一部のアプリケーションの休止時間をさらに削減することができます。 世代別 GC は、ヒープを 2 つの「世代」(「新しい世代」と「古い世代」) の領域に分けることにより、休止時間を削減します。オブジェクトはその経過時間によって、この領域のどちらかに入れられます。 新しい世代領域は、2 領域の小さい方で、若いオブジェクトが入ります。一方、古い世代領域は、 大きい方で、古いオブジェクトが入ります。オブジェクトは、まず新しい世代領域に割り振られて、 長期間存続した場合には、最終的に古い世代領域にレベル上げされます。
世代別 GC は、長期間存続しない多くのオブジェクトに依存しています。世代別 GC は、 多くのリサイクル可能なスペースを保有する、新しい世代領域のストレージを再利用することに 活動を集中させて、一時休止時間を削減します。 ヒープ全体をコレクションするために時折でも長い休止時間をとるのではなく、新しい世代を より頻繁に収集するので、新しい世代領域が小さければ、休止時間も比較的短くなります。 しかし、世代別 GC は、時間が経過すると存続期間が長いオブジェクトが非常に多くなり 古い世代領域がフルになる可能性があるという欠点があります。 そうした状態が発生したときに一時休止時間を最小限にするために、並行 GC と世代別 GC を組み合わせて 使用してください。 -Xgcpolicy:gencon オプションで、ガーベッジ・コレクションの一時休止の時間を 最小限にするために、並行 GC と世代別 GC を組み合わせて使用することを要求します。
Java ヒープがフルに近く、再利用できるガーベッジが少ししかない場合、即時使用可能なスペースがないため、新規オブジェクト用の要求がすぐには満たされないことがあります。
ヒープが容量いっぱいに近い状態で操作されている場合、どちらのガーベッジ・コレクション・オプションが使用されているのかに関係なく、アプリケーション・パフォーマンスは悪くなります。また、さらにヒープ・スペースの要求が続けば、アプリケーションは OutOfMemoryError を受け取り、その例外がキャッチされ処理されなければ、JVM は終了します。この時点で、JVM は診断時に使用できる Javadump ファイルを生成します。このような状態の場合、-Xmx オプションを使用してヒープ・サイズを増やすか、 使用中のオブジェクトの数を減らすことをお勧めします。
詳しくは、「Diagnostics Guide (英語)」を参照してください。
IBM SDK および Runtime Environment は、2002 年 1 月 1 日以降、欧州通貨共同体 (EMU) の国々のデフォルトの通貨 としてユーロを設定しています。2008 年 1 月 1 日以降、キプロスおよびマルタのデフォルトの通貨としてもユーロが設定されます。
各国の以前の通貨を使用する場合は、Java コマンド行で -Duser.variant=PREEURO を指定してください。
英国、デンマーク、あるいはスウェーデンのロケールを使用している場合で、ユーロを使用するには、 Java コマンド行で -Duser.variant=EURO を指定してください。
| | |バージョン 6 では、インドおよびタイ語の入力方式はデフォルトでは使用できません。インドおよびタイ語の入力方式を使用するには、入力方式の jar ファイルを Java 拡張パスに手動で組み込む必要があります。
バージョン 5.0 では、入力方式の jar ファイルは jre\lib\ext ディレクトリーに含まれており、JVM によって自動的にロードされていました。バージョン 6 では、入力方式の jar ファイルは jre\lib\im ディレクトリーに含まれており、インドおよびタイ語の入力方式を使用可能にするには、これを Java 拡張パスに手動で追加する必要があります。これは、以下のいずれかの方法を使用して実現できます。
|java -Djava.ext.dirs=C:¥Program Files¥IBM¥Java60¥jre\lib\ext;C:¥Program Files¥IBM¥Java60¥jre\lib\im <class>
|
SDK または Runtime Environment を別のディレクトリーにインストールした場合、SDK または Runtime Environment をインストールした |ディレクトリーで C:¥Program Files¥IBM¥Java60¥ を置き換えてください。
SDK for Windows には、Java ソフトウェア開発に必要な多数のツールおよびライブラリーが含まれています。
使用可能なツールの詳細については、SDK ツールおよび参照情報を参照してください。
| | |IBM SDK には、XML4J パーサー、XL XP-J パーサー、XL TXE-J 1.0 XSLT コンパイラー、XSLT4J XSLT インタープリターが組み込まれています。 |これらのツールを使用すると、XML 処理の実装とは関係なく、XML 文書を解析、検証、変換、およびシリアライズできます。
|
ファクトリー・ファインダーを使用して抽象ファクトリー・クラスの実装を検出します (XML プロセッサーの選択を参照)。 |ファクトリー・ファインダーを使用することにより、Java コードを変更せずに、他の XML ライブラリーを選択できます。
|IBM SDK for Java には、以下の XML ライブラリーが含まれています。
|XML4J は、以下の規格をサポートしている検証パーサーです。 |
|XML4J 4.5 は Apache Xerces-J 2.9.0 に基づいています。詳しくは、http://xerces.apache.org/xerces2-j/ を参照してください。
|XL XP-J 1.1 は高性能非検証パーサーであり、XML 1.0 および XML 1.1 文書のプル解析とストリーミング・シリアライゼーションのための双方向 API である StAX 1.0 (JSR 173) をサポートしています。XL XP-J 1.1 でサポートされている内容についての詳細は、XL XP-J 参照情報を参照してください。
|バージョン 5.0 では、IBM SDK for Java に XSLT4J のコンパイラーとインタープリターが組み込まれていました。 |XSLT4J インタープリターがデフォルトで使用されていました。
| |バージョン |6 では、IBM SDK for Java に XL TXE-J が組み込まれています。XL TXE-J には、XSLT4J 2.7.8 インタープリターと新規 XSLT コンパイラーが組み込まれています。 |この新規コンパイラーはデフォルトで使用されます。XSLT4J コンパイラーはすでに |IBM SDK |for Java に組み込まれていません。XL TXE-J へのマイグレーションについては、XL-TXE-J のマイグレーションを参照してください。
| |XL TXE-J は、次の規格をサポートしています。 |
|XML プロセッサーの選択は、 |サービス・プロバイダーを使用して実行されます。ファクトリー・ファインダーを使用している場合、Java は以下の場所で、使用するサービス・プロバイダーを検索します。 |
|以下のサービス・プロバイダーは、Java が使用する XML 処理ライブラリーを制御します。 |
|デフォルト XSLT プロセッサーは、XSLT4J インタープリターから XL TXE-J コンパイラーに置き換わりました。新しいライブラリーに対応するようにアプリケーションを準備するには、次の手順で操作します。
|
同じ変換を複数回適用する場合、XL TXE-J コンパイラーは XSLT4J インタープリターよりも高速です。各変換を一度ずつしか実行しない場合は、 |XL TXE-J コンパイラーのほうが XSLT4J インタープリターよりも低速です。これは、コンパイルと最適化のオーバーヘッドが原因です。
|XSLT4J インタープリターを引き続き XSLT プロセッサーとして使用するには、javax.xml.transform.TransformerFactory サービス・プロバイダーを |org.apache.xalan.processor.TransformerFactoryImpl に設定してください。
|XL-TXE-J コンパイラーにマイグレーションするには、次の手順で操作します。
|XSL4J コンパイラー属性 | |XL TXE-J コンパイラー属性 | |
---|---|
translet-name | |http://www.ibm.com/xmlns/prod/xltxe-j/translet-name | |
destination-directory | |http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory | |
package-name | |http://www.ibm.com/xmlns/prod/xltxe-j/package-name | |
jar-name | |http://www.ibm.com/xmlns/prod/xltxe-j/jar-name | |
generate-translet | |http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet | |
auto-translet | |http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet | |
use-classpath | |http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath | |
debug | |http://www.ibm.com/xmlns/prod/xltxe-j/debug | |
indent-number | |http://www.ibm.com/xmlns/prod/xltxe-j/indent-number | |
enable-inlining | |新規コンパイラーでは廃止 | |
XL XP-J ライブラリーと XL TXE-J XML ライブラリーは、SDK バージョン 6 の新機能です。この参照情報では、これらのライブラリーでサポートされる機能について説明します。
XL XP-J 1.1 は高性能非検証パーサーであり、XML 1.0 および XML 1.1 文書のプル解析とストリーミング・シリアライゼーションのための双方向 API である StAX 1.0 (JSR 173) をサポートしています。
XL XP-J でサポートされない StAX のオプション機能を次に示します。 |
|javax.xml.stream.XMLInputFactory 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLInputFactoryJavadoc を参照してください。
| |プロパティー名 | |サポートの有無 | |
---|---|
javax.xml.stream.isValidating | |なし。XL XP-J スキャナーでは検証はサポートされていません。 | |
javax.xml.stream.isNamespaceAware | |あり (true および false がサポートされています)。DOMSource から作成された XMLStreamReader では、名前空間の処理は、DOM ツリーを作成するときに使用されたメソッドによって異なります。この値の効果はありません。 | |
javax.xml.stream.isCoalescing | |あり | |
javax.xml.stream.isReplacingEntityReferences | |あり。DOMSource から作成された XMLStreamReader では、DOM ツリーでエンティティーが既に置換されている場合はこのパラメーターの効果はありません。 | |
javax.xml.stream.isSupportingExternalEntities | |あり | |
javax.xml.stream.supportDTD | |なし。DTD は常にサポートされています。この値を false に設定しても効果がありません。 | |
javax.xml.stream.reporter | |あり | |
javax.xml.stream.resolver | |あり | |
XL XP-J では、オプションのメソッド createXMLStreamReader(javax.xml.transform.Source) もサポートされています。このメソッドは、DOM ソースおよび SAX ソースからの StAX リーダーを作成できるようにします。
|javax.xml.stream.XMLStreamReader 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLStreamReader Javadoc を参照してください。
| |プロパティー名 | |サポートの有無 | |
---|---|
javax.xml.stream.entities | |あり | |
javax.xml.stream.notations | |あり | |
XL XP-J では、javax.xml.stream.isInterning プロパティーもサポートされています。このプロパティーは、API 呼び出しから戻された XML 名と名前空間 URI がパーサーにより拘束されていたかどうかを示すブール値を戻します。
|javax.xml.stream.XMLOutputFactory 実装でサポートされるプロパティーを次に示します。これらのプロパティーの説明については、XMLOutputFactory Javadoc を参照してください。
| |プロパティー名 | |サポートの有無 | |
---|---|
javax.xml.stream.isRepairingNamespaces | |あり | |
javax.xml.stream.XMLStreamWriter 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLStreamWriter Javadoc を参照してください。
| |プロパティー名 | |サポートの有無 | |
---|---|
javax.xml.stream.isRepairingNamespaces | |あり | |
XMLStreamWriter オブジェクトのプロパティーは読み取り専用です。
| | |XL TXE-J は、XSLT4J 2.7.8 インタープリターと XSLT コンパイラーが組み込まれた XSLT ライブラリーです。
機能 | |XSLT4J インタープリター (組み込み) | |XSLT4J コンパイラー (非組み込み) | |XL TXE-J コンパイラー (組み込み) | |
---|---|---|---|
http://javax.xml.transform.stream.StreamSource/feature 機能 | |あり | |あり | |あり | |
http://javax.xml.transform.stream.StreamResult/feature |機能 | |あり | |あり | |あり | |
http://javax.xml.transform.dom.DOMSource/feature 機能 | |あり | |あり | |あり | |
http://javax.xml.transform.dom.DOMResult/feature 機能 | |あり | |あり | |あり | |
http://javax.xml.transform.sax.SAXSource/feature 機能 | |あり | |あり | |あり | |
http://javax.xml.transform.sax.SAXResult/feature 機能 | |あり | |あり | |あり | |
http://javax.xml.transform.stax.StAXSource/feature 機能 | |あり | |なし | |あり | |
http://javax.xml.transform.stax.StAXResult/feature 機能 | |あり | |なし | |あり | |
http://javax.xml.transform.sax.SAX TransformerFactory/feature |機能 | |あり | |あり | |あり | |
http://javax.xml.transform.sax.SAX TransformerFactory/feature/xmlfilter |機能 | |あり | |あり | |あり | |
http://javax.xml.XMLConstants/feature/secure-processing |機能 | |あり | |あり | |あり | |
http://xml.apache.org/xalan/features/incremental 属性 | |あり | |なし | |なし | |
http://xml.apache.org/xalan/features/optimize 属性 | |あり | |なし | |なし | |
http://xml.apache.org/xalan/properties/source-location |属性 | |あり | |なし | |なし | |
translet-name 属性 | |該当なし | |あり | |あり (新規名付き) | |
destination-directory 属性 | |該当なし | |あり | |あり (新規名付き) | |
package-name 属性 | |該当なし | |あり | |あり (新規名付き) | |
jar-name 属性 | |該当なし | |あり | |あり (新規名付き) | |
generate-translet 属性 | |該当なし | |あり | |あり (新規名付き) | |
auto-translet 属性 | |該当なし | |あり | |あり (新規名付き) | |
use-classpath 属性 | |該当なし | |あり | |あり (新規名付き) | |
enable-inlining 属性 | |なし | |あり | |なし (TL TXE-J では廃止) | |
indent-number 属性 | |なし | |あり | |あり (新規名付き) | |
debug 属性 | |なし | |あり | |あり (新規名付き) | |
Java 拡張 | |あり | |あり (短縮構文のみ。xalan:component/xalan:script |構文はサポートされません。) | ||
JavaScript 拡張 | |あり | |なし | |なし | |
拡張エレメント | |あり | |なし | |なし | |
EXSLT 拡張機能 | |あり | |あり (動的は除く) | |あり (動的は除く) | |
リダイレクト拡張 | |あり | |あり (redirect:open および redirect:close は除く) | |あり | |
出力拡張 | |なし | |あり | |あり | |
nodeset 拡張 | |あり | |あり | |あり | |
NodeInfo 拡張機能 | |あり | |なし | |なし | |
SQL ライブラリー拡張 | |あり | |なし | |なし | |
pipeDocument 拡張 | |あり | |なし | |なし | |
evaluate 拡張 | |あり | |なし | |なし | |
tokenize 拡張 | |あり | |なし | |なし | |
XML 1.1 | |あり | |あり | |あり | |
Process コマンドでは、StAX ストリーム処理を使用して変換を行うには -FLAVOR sr2sw を、StAX イベント処理の場合は -FLAVOR er2ew を使用してください。
|新規コンパイラーは、 |org.apache.xalan.xsltc.dom.XSLTCDTMManager サービス・プロバイダーを検索しません。その代わり、StreamSource が使用されている場合、コンパイラーはハイパフォーマンス XML パーサーに切り替わります。
|XL TXE-J では、インライン化は廃止されました。 |
|org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl クラスはサポートされなくなりました。
| |旧バージョンの Xerces (2.0 より前) または Xalan (2.3 より前) を |endorsed ディレクトリーに入れて使用している場合、アプリケーションを起動したときに NullPointerException が発生する可能性があります。 |この例外は、これらの古いバージョンが jaxp.properties ファイルを正しく処理しないために起きます。
|
この状態を避けるために、以下の次善策のいずれかを使用してください。 | |
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
または
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
または
|set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
Java プログラムをデバッグするには、Java Debugger (JDB) アプリケーション、あるいは SDK for Windows で提供される Java Platform Debugger Architecture (JPDA) を 使用して通信する他のデバッガーを使用できます。
Java を使用した問題診断について詳しくは、「Diagnostics Guide (英語)」を参照してください。
Java Debugger (JDB) は、SDK for Windows に組み込まれています。このデバッガーは、 jdb コマンドで呼び出されると、JPDA を使用して JVM に接続します。
Java アプリケーションをデバッグするには、以下のようにします。
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <class>JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。
jdb -attach <port>デバッガーが JVM に接続したら、一連のコマンドを実行して Java アプリケーションを 検査し制御することができます。例えば、run と入力して Java アプリケーションを 開始させることができます。
JDB オプションについて詳しく調べるには、次のように入力します。
jdb -help
JDB コマンドについて詳しく調べるには、次のようにします。
また、JDB を使用して、リモート・マシンで実行中の Java アプリケーションもデバッグできます。 JPDA は、TCP/IP ソケットを使用してリモート JVM に接続します。
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <class>JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。
jdb -connect com.sun.jdi.SocketAttach:hostname=<host>,port=<port>
Java Virtual Machine Debugging Interface (JVMDI) は、このリリースでサポートされていません。これは、Java Virtual Machine Tool Interface (JVMTI) に置き換えられています。
JDB と JPDA とその使用法について詳しくは、以下の Web サイトを参照してください。
Java アプリケーションの中には、それが 32 ビット JVM で実行されているか、 64 ビット JVM で実行されているかを判別可能でなければならないものがあります。例えば、アプリケーションにネイティブ・コード・ライブラリーがある場合、 32 ビットと 64 ビットの両方の稼働モードをサポートするプラットフォーム用に、 そのライブラリーは、32 ビットおよび 64 ビット形式で別々にコンパイルされる必要があります。 この場合、32 ビット・コードと 64 ビット・コードは混用できないため、 アプリケーションが実行時に正しいライブラリーをロードしなければなりません。
システム・プロパティー com.ibm.vm.bitmode を使用して、 アプリケーションは、JVM の稼働モードを判別することができます。 これは、以下の値を戻します。
アプリケーション・コード内から com.ibm.vm.bitmode プロパティーを検査するには、次の呼び出しを使用します。
System.getProperty("com.ibm.vm.bitmode");
JVM に関係のあるシグナルが生じると、シグナル・ハンドラーが呼び出されます。このシグナル・ハンドラーは、Java スレッドのために呼び出されたのか、または Java 以外のスレッドのために呼び出されたのかを判別します。
シグナルが Java スレッドのためのものである場合、JVM がシグナル処理の制御を行います。このシグナルの アプリケーション・ハンドラーがインストールされていて、 -Xnosigchain コマンド行オプションを指定しなかった場合、このシグナルのアプリケーション・ハンドラーは JVM の処理終了後に呼び出されます。
シグナルが Java 以外のスレッドのためのものであり、インストール済みのアプリケーションに、以前に JVM がそのシグナル用の独自のハンドラーをインストールしている場合、 制御はそのハンドラーに与えられます。そうでないと、シグナルが JVM または Java アプリケーションによって要求されても、シグナルは無視されるか、または、デフォルトのアクションがとられます。
シグナルが外部で生成されると (例えば、CTRL-BREAK キーを押した場合)、シグナル・ハンドラーの新規スレッドが作成されます。この場合、 JVM シグナル・ハンドラーがその処理を実行します。このシグナル用アプリケーション・ハンドラーが インストールされていて、-Xnosigchain コマンド行オプションを指定しなかった場合には、 このシグナル用のアプリケーション・ハンドラーが呼び出されます。
例外およびエラーのシグナルの場合、JVM は以下のいずれかを行います。
割り込みシグナルの場合にも JVM は制御されたシャットダウン・シーケンスに入りますが、この場合は、以下を行う正常終了として扱われます。
このシャットダウンは、Java メソッド System.exit() を呼び出すことによって開始されるシャットダウンと同一です。
JVM が使用するその他のシグナルは内部制御の目的のものであり、終了の原因となることはありません。関係のある 唯一の制御シグナルは SIGBREAK であり、これにより Javadump が生成されます。
シグナルのタイプには、割り込みおよび制御があります。
下記の表 7 は、JVM が使用するシグナルを示したものです。 以下に、タイプまたは使用法ごとに表にグループ化したシグナルを示します。
シグナル名 | シグナル・タイプ | 説明 | -Xrs による使用不可 |
---|---|---|---|
SIGINT (2) | 割り込み | 対話式アテンション (CTRL-C)。 JVM は正常に終了します。 | あり |
SIGTERM (15) | 割り込み | 終了要求。JVM は正常に終了します。 | あり |
SIGBREAK | 制御 | 端末からのブレーク・シグナル。デフォルトでは、Javadump が起動されます。 | あり |
IBM JVM は、構造化された例外処理 および SetConsoleCtrlHandler() API を使用します。これらは、-Xrs で使用不可になります。Windows では、-Xnosigchain は無視されます。
-Xrs (シグナル使用の削減) オプションを使用して、 JVM がほとんどのシグナルを処理してしまうのを防止します。詳しくは、 Sun の 『Java application launcher』ページを参照してください。
JVM スレッド上のシグナル 2 (SIGINT) および 15 (SIGTERM) により、 JVM はシャットダウンします。したがって、アプリケーション・シグナル・ハンドラーでは、JVM を必要としなくなった場合を除き、 リカバリーを試みるべきではありません。
Runtime Environment にはシグナル・チェーニングが含まれています。シグナル・チェーニングにより、JVM は、独自のシグナル・ハンドラーをインストールするネイティブ・コードとの、より効率的な相互操作が可能となります。
シグナル・チェーニングにより、アプリケーションでは、msvcrt.dll の前に共用ライブラリー jsig.dll にリンクしてロードすることが可能になります。jsig.dll ライブラリーにより、signal() の呼び出しが確実にインターセプトされ、それらのハンドラーが JVM のシグナル・ハンドラーを置き換えることがなくなります。代わりに、これらの呼び出しは、新しいシグナル・ハンドラーを保管するか、または JVM がインストールしたハンドラーの後にそれらを「チェーニング」します。後で、これらのシグナルのいずれかが生じ、JVM をターゲットとしたものではないことが分かった場合、プリインストールされたハンドラーが起動します。
libjsig.dll ライブラリーも、アプリケーションから JVM シグナル・ハンドラーを隠します。このため、JVM が開始した後で行われた signal()、sigset()、および sigaction() などの呼び出しでは、JVM のシグナル・ハンドラーへの参照を戻すことがなくなりますが、JVM の開始前にインストールされたハンドラーがあれば、代わりにそれを戻します。
環境変数 JAVA_HOME は、SDK の場所 (例えば C:¥Program Files¥IBM¥Java60¥) に設定してください。
jsig.dll を使用するには、それを JVM を作成または組み込むアプリケーションとリンクします。
ネイティブ・プログラムが JNI_CreateJavaVM() API 呼び出しで指定できる有効な JNI バージョン番号は、JNI_VERSION_1_2(0x00010002) および JNI_VERSION_1_4(0x00010004) です。
このバージョン番号で決まるのは、使用する JNI ネイティブ・インターフェースのレベルのみです。 作成される JVM の実際のレベルは、JSE ライブラリーによって指定されます (つまり、v6)。 JNI インターフェース API は、JVM によって実装される言語仕様や、 クラス・ライブラリー API、その他の範囲の JVM 動作に影響しません。 詳しくは、『http://java.sun.com/javase/6/docs/technotes/guides/jni/』を参照してください。
32 ビット用に作成されたものと 64 ビット用に作成されたものの 2 つの JNI ライブラリーがアプリケーションで必要な場合、com.ibm.vm.bitmode システム・プロパティーを使用して、32 ビットまたは 64 ビット JVM のどちらで実行しているかを判別し、適切なライブラリーを選択します。
大規模ページをサポートするシステムでこのサポートを使用可能にするには、 -Xlp オプションを指定して Java を始動します。
大規模ページは、多くのメモリーを割り振って頻繁にそのメモリーにアクセスする アプリケーションのパフォーマンスを向上させるために使用するものです。 大規模ページによるパフォーマンスの向上は、 主に Translation Lookaside Buffer (TLB) のミスの数を減らすことによって実現します。 TLB は、より大きな仮想メモリー範囲をマップし、それにより、この向上をもたらします。
JVM が大規模ページを使用するためには、システムで、十分な数の連続した大規模ページが使用可能でなければなりません。 十分なページが使用可能であっても、大規模ページを割り振れない場合、大規模ページが連続していない可能性があります。
大規模ページの割り振りは、JVM ユーザーのローカル管理ポリシーが「Lock pages in memory」を許可するように構成されている場合にのみ、正常終了します。
Java Platform, Standard Edition (JSE) は、Sun の準拠資料に定義されている仕様は最小限サポートしています。場合によっては、IBM JSE ORB で、より新しいバージョンの仕様をサポートしている場合もあります。
サポートされる最小限の仕様は、『Official Specifications for CORBA support in Java SE 6』に定義されています。
この SDK は、OMG 資料「formal/99-10-07」の第 13 章および第 15 章の CORBA 2.3.1 仕様で定義されているように、すべてのバージョンの GIOP をサポートしています。
http://www.omg.org/cgi-bin/doc?formal/99-10-07
双方向 GIOP は、サポートされていません。
この SDK は、資料「ptc/01-03-04」で OMG によって定義されているように ポータブル・インターセプターをサポートします。この資料は、以下のサイトから入手できます。
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
ポータブル・インターセプターは、ORB へのフックで、これを使用して ORB サービスは ORB の実行の通常フローをインターセプトすることができます。
この SDK は、資料「ptc/00-08-07」で OMG によって定義されているように、 Interoperable Naming Service をサポートします。この資料は、以下のサイトから入手できます。
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
一時ネーム・サーバー (tnameserv コマンド) が使用するデフォルトのポートは、ORBInitialPort パラメーターが指定されていない場合には、900 から 2809 に変更されます。これは CORBA ネーミング・サービス用に IANA (Internet Assigned Number Authority) で登録されているポート番号です。 このデフォルトに依存する プログラムは、このバージョンで作業する場合に更新しなければならない可能性があります。
一時ネーム・サーバーから戻される初期コンテキストは、現在、 org.omg.CosNaming.NamingContextExt です。コンテキスト org.omg.CosNaming.NamingContext への参照が限られている既存のプログラムは、そのまま動作するので、再コンパイルする必要はありません。
ORB は、Interoperable Naming Service 仕様で定義されている -ORBInitRef と -ORBDefaultInitRef パラメーターをサポートし、ORB::string_to_object 操作では、現在、 Interoperable Naming Service 仕様で定義されている ObjectURL ストリング・フォーマット (corbaloc: および corbaname:) がサポートされています。
OMG は、サービスを Interoperable Naming Service に登録するのに、 メソッド ORB::register_initial_reference を指定します。しかし、このメソッドは バージョン 6 の Sun Java Core API では使用できません。 現行バージョンでサービスの登録が必要なプログラムは、このメソッドを IBM 内部の ORB 実装クラスで呼び出す必要があります。例えば、サービス「MyService」を登録するには以下のようにします。
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService", serviceRef);
ここで、orb は、ORB.init() から戻される org.omg.CORBA.ORB のインスタンスで、 serviceRef は、ORB に接続される CORBA オブジェクトです。この手段は一時的なもので、今後のバージョンと互換性はなく、また、IBM 以外の ORB にも 移植できません。
ランタイム・デバッグ機能により、保守容易度が向上しました。これは、問題診断に有効であり、 IBM サービス担当員から要求される場合もあります。
例えば、イベントとフォーマット済み GIOP メッセージをコマンド行からトレースするには、以下のように入力します。
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true <myapp>
パフォーマンスの低下につながるので、通常の業務ではトレースをオンにしないようにしてください。 トレースをオフに切り替えても、FFDC (First Failure Data Capture) は作動していて、重大なエラーは報告されます。デバッグの出力ファイルが生成されたら、それを確認して問題について調べてください。例えば、 サーバーが ORB.shutdown() を実行せずに停止した可能性などがあげられます。
トレース出力の内容およびフォーマットは、バージョンによって異なります。
ORB を調整して、特定のネットワークとうまく連動させることができます。ORB の調整に必要なプロパティーについて、以下で説明します。
フラグメントを使用不可にするには、以下のようにフラグメント・サイズを 0 バイトにします。
java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
Java SecurityManager を使用して実行中に、CORBA API クラスのいくつかのメソッドを呼び出すと、 権限チェックが行われて、その結果 SecurityException になることがあります。 ご使用のプログラムが、これらのメソッドのいずれかを使用している場合は、必要な権限が付与されている ことを確認してください。
クラス/インターフェース | メソッド | 必要な権限 |
---|---|---|
org.omg.CORBA.ORB | init | java.net.SocketPermission resolve |
org.omg.CORBA.ORB | connect | java.net.SocketPermission listen |
org.omg.CORBA.ORB | resolve_initial_references | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _is_a | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _non_existent | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | OutputStream _request (String, boolean) | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _get_interface_def | java.net.SocketPermission connect |
org.omg.CORBA. Request | invoke | java.net.SocketPermission connect |
org.omg.CORBA. Request | send_deferred | java.net.SocketPermission connect |
org.omg.CORBA. Request | send_oneway | java.net.SocketPermission connect |
javax.rmi. PortableRemoteObject | narrow | java.net.SocketPermission connect |
ORB 実装クラスのリストです。
このリリースの ORB 実装クラスは以下のとおりです。
これらは、デフォルト値です。これらのプロパティーを設定しないか、または、 実装クラスを直接参照することをお勧めします。移植性を保つためには、実装ではなく、 CORBA API クラスのみを参照してください。これらの値は、今後のリリースで変更になる可能性があります。
Java リモート・メソッド呼び出し (RMI) は、分散 Java プログラミングのための簡単なメカニズムです。RMI over IIOP (RMI-IIOP) では、Common Object Request Broker Architecture (CORBA) 標準の Internet Inter-ORB Protocol (IIOP プロトコル) を使用し、基本の Java RMI を拡張して通信を行います。これにより、他の CORBA オブジェクト・リクエスト・ブローカー (ORB) が Java で実装されていても、他のプログラム言語で実装されていても、 それらとの直接対話が可能になります。
以下の資料が利用可能です。
デフォルトでは、RMI Connection Handlers のスレッド・プーリングは使用可能になっていません。
RMI TCPTransport レベルで実装された接続プーリングを使用可能にするには、 以下のオプションを設定します。
-Dsun.rmi.transport.tcp.connectionPool=true
このバージョンの Runtime Environment には、接続プール内のスレッド数を制限するために使用可能な設定はありません。
Java 5.0 以降、Sun によりIBM BigDecimal クラスが java.math.BigDecimal として採用されました。com.ibm.math.BigDecimal クラスは IBM が将来使用するものとして予約されており、現在は推奨されていません。既存の Java コードをマイグレーションして、java.math.BigDecimal を使用してください。
新しい java.math.BigDecimal は、以前の java.math.BigDecimal と com.ibm.math.BigDecimal の両方と同じメソッドを使用しています。 java.math.BigDecimal を使用している既存のコードは、そのまま正常に動作します。2 つのクラスは直列化されません。
既存の Java コードを java.math.BigDecimal クラスを使用するようにマイグレーションするには、ご使用の .java ファイルの先頭にある import ステートメントを、import com.ibm.math.*; から import java.math.*; に変更してください。
Java Plug-in は、ブラウザー内で Java アプリケーションを実行するために使用します。appletviewer は、ブラウザー内で実行するよう設計されているアプリケーションをテストするために使用します。Java Web Start は、ネットワーク上にデスクトップの Java アプリケーションをデプロイするために使用するものであり、それらのアプリケーションを常に最新の状態にする仕組みが備わっています。
Java Plug-in は Web ブラウザー・プラグインです。ブラウザーでアプレットを実行するには、Java プラグインを使用します。
ブラウザーが「ハング」しないように、アプレットがロードを完了できるようにする必要があります。 例えば、「戻る」ボタンを使用してから、 アプレットのロード中に「進む」ボタンを使用すると、HTML ページがロードできない可能性があります。
Java Plug-in に関しては、Sun の http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/ に記述があります。
Java Plug-in では、Internet Explorer、Netscape、Mozilla、 および Mozilla Firefox がサポートされています。
ブラウザー | サポートされるバージョン |
---|---|
Internet Explorer | 6.0 SP1, 7.0 |
Netscape (Windows Vista ではサポートされません) | 7.2 |
Mozilla (Windows Vista ではサポートされません) | 1.7, 1.8 |
Firefox | 2.0 |
ブラウザーのこれ以降のマイナー・リリースもサポートされています。
Internet Explorer 5.01 は Windows 2000 のデフォルト・ブラウザーですが、サポートされていません。
静的バージョン管理では、アプレットが、特定の JVM バージョンを実行環境として要求できます。この機能を使用すると、新規 JVM にアップグレードしたシステムに存在する古いセキュリティーの脆弱性をアプレットが悪用することもできるため、Internet Explorer では Secure Static Versioning が使用されるようになっています。
デフォルトでは、最後にインストールされた JVM ですべてのアプレットが実行されます。SSV を無効にするには、次のレジストリー・キーを 0 に設定します。
HKEY_LOCAL_MACHINE¥Software¥IBM¥Java Deployment¥Policy¥EnableSecureStaticVersioning
レジストリー・キーが存在しない場合は、SSV が使用可能になっています。
Internet Explorer でサード・パーティーのブラウザー拡張が使用不可に設定されている場合は、SSV が機能しません。サード・パーティーのブラウザー拡張を使用可能にするには、次の手順を実行します。
SSV が使用された後にサード・パーティーのブラウザー拡張が使用不可になっても、SSV は機能し続けます。
Mozilla および Firefox ブラウザーを保護するため、Internet Explorer のプラグインによって、Mozilla および Firefox の Plug-in ディレクトリーから Java Plug-in が自動的に削除されます。この処理は、アプレットが Internet Explorer で実行されるたびに生じます。
Mozilla または Firefox に Java Plug-in を再インストールするには、Java コントロール・パネルを使用します。
特定のブラウザーによる制約のために、org.w3c.dom.html パッケージのすべての機能を実装できない場合があります。
次のエラーのいずれかがスローされます。
Java Plug-in は、2 バイト文字を (例えば、中国語 (繁体字) BIG-5、韓国語、日本語) タグ <APPLET>、<OBJECT>、および <EMBED> などのパラメーターとしてサポートします。Java Plug-in がパラメーターを解析できるように、HTML 文書の正しい文字エンコード方式を選択しなければなりません。
HTML 文書の文字エンコード方式は、 <HEAD> セクションで <META> タグを使用して次のように指定します。
<meta http-equiv="Content-Type" content="text/html; charset=big5">
この例は、ブラウザーに、中国語 BIG-5 文字エンコード方式を使用して HTML ファイルを解析するように指示するものです。
アプレット・ビューアーを使用すれば、Web ページ (HTML ファイル) 内から APPLET タグを使った 参照で呼び出される 1 つ以上のアプレットを実行できます。 アプレット・ビューアーは、HTML ファイルで APPLET タグを見つけると、タグで指定されているとおりに 別のウィンドウでそのアプレットを実行します。
アプレット・ビューアーは、アプレットを表示するためのものなので、HTML タグを数多く含む Web ページ全体は表示できません。 Web ページ上で APPLET タグのみを解析し、他の HTML タグは解析しません。
アプレット・ビューアーでアプレットを実行するには、以下のコマンドを使用します。
コマンド・プロンプトで、以下を入力します。
appletviewer <name>
ここで、<name> には、以下のいずれかを指定します。
例えば、アプレットの呼び出し元の HTML ファイルでアプレット・ビューアーを起動するには、コマンド・プロンプトで次のように入力します。
appletviewer <demo>¥GraphLayout¥example1.html
ここで、<demo> は、デモ・パッケージを unzip した先の 絶対パスに置き換えます。
Web ページでアプレット・ビューアーを呼び出すには、コマンド・プロンプトで次のように入力します。
appletviewer http://java.sun.com/applets/NervousText/example1.html
アプレット・ビューアーは、<META> タグの charset オプションは認識しません。アプレット・ビューアーがロードするファイルが、システム・デフォルトとしてエンコードされていないと、I/O 例外が発生する可能性があります。この例外を避けるには、appletviewer を実行するときに、 -encoding オプションを使用します。例えば、次のようにします。
appletviewer -encoding JISAutoDetect sample.html
固有の CLSID のセットが Version 6 から IBM JVM に追加されました。
以下が新しい CLSID です。
1ACECAFE-0016-0000-0000-ABCDEFFEDCBA 1ACECAFE-0016-0000-0000-ABCDEFFEDCBB 1ACECAFE-0016-0000-0000-ABCDEFFEDCBC
上記の CLSID は、アプレットの OBJECT タグで参照できます。
また、以下の既存の CLSID も互換性目的でサポートされています。
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC
アプレットをデバッグするには、アプレット・ビューアーの -debug オプションを使用します。
例えば、次のようにします。
cd demo\applets\TicTacToe ..\..\..\bin\appletviewer -debug example1.html
アプレット・ビューアーを使用してアプレットをデバッグする方法についての資料は、 Sun の Web サイト http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html で参照できます。
Java Web Start は、Java アプリケーションのデプロイメントで使用します。
Web Start を使用すると、アプリケーションの起動および管理を Web から直接行うことができます。インストール時間を最小化するために、アプリケーションがキャッシュされます。新規バージョンが使用可能になると、アプリケーションは自動的にアップグレードされます。
Web Start は、http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources に文書化されている、以下の java-vm-args をサポートします。
IBM Web Start では、ガーベッジ・コレクション・ポリシーを設定する -Xgcpolicy もサポートします。
Web Start をサポートするブラウザーについて詳しくは、 『サポートされるブラウザー』を参照してください。
Web Start について詳しくは、
アプリケーションのデプロイについて詳しくは、
Web Start は、Web ページまたはコマンド行から実行できます。Web Start アプリケーションは、Java アプリケーション・キャッシュに保管されます。
Web Start は、以下のいくつかの異なる方法で起動できます。
javaws <URL>ここで、<URL> は .jnlp ファイルの場所です。
C:¥Program Files¥IBM¥Java60¥jre\bin\javaws| -viewer
すべての Java Web Start アプリケーションは、Java アプリケーション・キャッシュに保管されます。アプリケーションがダウンロードできるのは、最新バージョンがキャッシュにない場合に限られます。
静的バージョン管理を使用すると、Web Start アプリケーションで稼働させる特定の JVM バージョンを要求できます。この機能を使用すると、アプリケーションは、新規 JVM にアップグレードされたシステムで古いセキュリティーのぜい弱性を利用することができるため、Secure Static Versioning (SSV) がデフォルトで使用されます。
SSV を使用する場合、特定の JVM の使用を要求する未署名 Web Start アプリケーションを実行しようとすると警告されます。署名付きアプリケーションと、JVM の最新バージョンを要求するアプリケーションは正常に稼働します。
SSV は、deployment.properties ファイルの deployment.javaws.ssv.enabled プロパティーを false に設定することによって使用不可にできます。
Java アプリケーションは一般にクラス、リソース、およびデータ・ファイルで構成されています。
Java アプリケーションを出荷する場合、 ソフトウェア・パッケージは、多くの場合、以下のパーツから構成されます。
アプリケーションを実行するには、ユーザーに Runtime Environment for Windows が必要です。 SDK for Windows ソフトウェアには Runtime Environment が含まれます。ただし、 ユーザーが SDK for Windows ソフトウェアをインストール済みであることを前提にすることはできません。
SDK for Windows ソフトウェアのライセンスでは、 SDK のファイルをアプリケーションとともに再配布することが許可されません。 ライセンス交付を受けた SDK for Windows がターゲット・マシンにインストールされていることを確認してください。
クラス・データの共用によって、複数の JVM がメモリー内の単一スペースを共用できます。
Java 仮想マシン (JVM) では、ディスクのメモリー・マップ・キャッシュ・ファイルにデータを保管することによって、JVM 間でクラス・データを共用することができます。複数の JVM がキャッシュを共用する場合、共用によって全体の仮想メモリーの使用量が削減されます。また、共用によって、キャッシュ作成後の JVM の起動時間も短縮されます。共用クラス・キャッシュは、どのアクティブな JVM からも独立しており、破棄されるまで存続します。
共用キャッシュには、以下を含むことができます。
クラス・データ共用は、メモリー・フットプリントを減らし、JVM 起動時間を改善するための透過的な手法です。|Java 6 |には、キャッシュの管理、分離、およびパフォーマンスに関連する機能が拡張され、新機能が導入されました。
JVM の開始時、-Xshareclasses オプションを使用して、クラス・データ共用を使用可能にすることができます。 JVM は、既存のキャッシュに接続するか、キャッシュが存在しない場合は新規キャッシュを作成します。
JVM によってロードされるすべてのブートストラップおよびアプリケーション・クラスが、 デフォルトで共用されます。カスタム・クラス・ローダーは、アプリケーション・クラス・ローダーを継承している場合は 自動的にクラスを共用します。継承していない場合は、JVM で提供される Java ヘルパー API を使用して、そのキャッシュにアクセスする必要があります。(カスタム・クラス・ローダーの共用クラスへの適応を参照)
|JVM は、特定のメソッドの AOT (ahead-of-time) コンパイル・コードをキャッシュに格納します。これにより、後続の JVM の起動時間が短縮されます。AOT コンパイル・コードは、実際には JVM 間で共用されませんが、JVM 始動時のコンパイル時間を短縮する目的でキャッシュに入れられます。キャッシュに入れられる AOT コードの量は、ヒューリスティックに判別されます。キャッシュに格納されるメソッドを制御することはできませんが、AOT コードの格納に充てられるキャッシュ・スペースの容量の上限と下限を設定できます。また、AOT キャッシュを完全に使用不可に設定することもできます。 |詳しくは、クラス・データ共用の使用可能化と構成を参照してください。
|JVM は、読み取り/書き込みアクセス権限または読み取り専用アクセス権限でキャッシュにアクセスします。 読み取り/書き込みアクセス権限でキャッシュに接続する JVM は、このキャッシュを更新できます。キャッシュに対して同時に読み取り操作を実行できる JVM の数に制限はありません。これは、他の JVM がキャッシュに対して書き込み操作を実行している場合でも同様です。
実行時バイトコード変更を使用する場合は、注意が必要です。 詳しくは、実行時バイトコード変更を参照してください。
共用クラス・キャッシュは任意の JVM の存続期間を超えて存続するため、 ファイル・システムで JAR やクラスに行われた可能性がある変更を反映するよう、 キャッシュは動的に更新されます。動的更新により、キャッシュを使用するアプリケーションでキャッシュを意識する必要がなくなります。
共用クラス・キャッシュへのアクセスは、オペレーティング・システムの許可と Java セキュリティーの許可によって制限されます。クラス・データの共用を登録しているクラス・ローダーのみが、共用クラス・キャッシュを更新できます。
|キャッシュ・メモリーは、メモリー・ページ保護機能により偶発的/意図的な破損から保護されています。これは破損から完全に保護することを保証するものではありません。これは、JVM はページへの書き込み時にページの保護を解除する必要があるためです。キャッシュが変更されないことを保証する唯一の方法は、キャッシュを読み取り専用で開くことです。
Java SecurityManager がインストールされている場合、java.policy ファイルに SharedClassPermission 行を追加することによって、デフォルト・ブートストラップ、アプリケーション、および拡張クラス・ローダー以外のクラス・ローダーにクラス共用の許可を付与する必要があります。(SharedClassPermission の使用を参照) RuntimePermission 『createClassLoader』 は、新しいクラス・ローダーの作成を制限します。したがって、キャッシュへのアクセスも制限します。
1 つのシステムに複数のキャッシュが存在することが可能で、それらは、 -Xshareclasses コマンドのサブオプションとして名前で指定されます。 JVM が一度に接続できるキャッシュは 1 つのみです。
始動時にデフォルトのキャッシュ・サイズを指定変更するには、-Xscmx<n><size> を使用します。キャッシュの存続期間中このサイズは変更されません。キャッシュは、-Xshareclasses コマンドのサブオプションを使用して明示的に破棄されるか、または キャッシュ・ファイルが手動で削除されるまで存在します。
キャッシュ・ユーティリティーはすべて、-Xshareclasses コマンドのサブオプションです。 クラス・データ共用の使用可能化と構成を参照するか、 -Xshareclasses:help を使用して、使用可能なサブオプションのリストを参照してください。
クラス・データ共用とキャッシュ管理ユーティリティーを制御するには、java ランチャーのコマンド行オプションを使用します。
<size> パラメーターを取るオプションでは、その数値の後に、キロバイトを示す「k」または「K」、メガバイトを示す「m」または「M」、あるいはギガバイトを示す「g」または「G」を付け加えてください。
一部のキャッシュ・ユーティリティーは、以前のバージョンの Java のキャッシュや、ビット幅が異なる JVM で作成されたキャッシュでも機能します。このようなキャッシュは「非互換」キャッシュと呼ばれます。
-Xshareclasses オプションで、以下のサブオプションを使用できます。
name、cacheDir、および nonpersistent サブオプションにより指定されるキャッシュの詳細情報を表示します。すべてのクラスは、ロード元の位置への参照とともに発生順にリストされます。 クラス・メソッドの AOT コードもリストされます。
「Diagnostics Guide (英語)」を参照してください。
共用クラス・データ・キャッシュのライフ・サイクルの概要を説明します。キャッシュ管理ユーティリティーの例も示します。
クラス・データ共用を使用可能にするには、アプリケーション・コマンド行に -Xshareclasses[:name=<name>] を追加します。
JVM は、指定された名前の既存キャッシュに接続するか、その名前の新しいキャッシュを作成します。新しいキャッシュが作成された場合、キャッシュがフルになるまで、 ロードされるすべてのブートストラップおよびアプリケーション・クラスがそれに取り込まれます。 2 つ以上の JVM が同時に始動された場合、 それらすべてが同時にキャッシュにデータの取り込みを行います。
キャッシュが作成されたことを確認するには、java -Xshareclasses:listAllCaches を実行します。 共用されるクラス数とクラス・データ量を確認するには、java -Xshareclasses:[name=<name>],printStats を実行します。(このユーティリティーは、アプリケーション JVM の終了後か、別のコマンド・ウィンドウで実行できます。)
JVM が稼働している間のキャッシュ使用量について詳細にフィードバックするには、verbose サブオプションを使用します。 例えば、java -Xshareclasses:[name=<name>],verbose と指定します。
キャッシュからロードされる、またはキャッシュに保管されるクラスを確認するには、 アプリケーション・コマンド行に -Xshareclasses:[name=<name>],verboseIO を追加します。
作成されたキャッシュを削除するには、java -Xshareclasses:[name=<name>],destroy を実行します。 キャッシュに多くの stale クラスが含まれるか、キャッシュがフルで、より大きいキャッシュを作成したい場合にのみ、 キャッシュを削除する必要があります。
キャッシュ・サイズは、個別のアプリケーションに応じて調整することが推奨されます。 これは、デフォルトが最適サイズである可能性が低いためです。 最適なキャッシュ・サイズを判別する最も良い方法としては、 (-Xscmx を使用して) 大容量のキャッシュを指定してアプリケーションを実行し、 printStats を使用して保管されたクラス・データの量を判別するという方法があります。 printStats で示された値に、予備のために少量を加算します。 クラスは JVM 存続期間中のどの時点でもロード可能であるため、 この分析はアプリケーションの終了後に行うのが最適です。 ただし、キャッシュがフルであることが、それに接続された JVM のパフォーマンスや機能に悪影響を与えることはありません。そのため、キャッシュ・サイズを必要なものより小さくすることは、非常に合理的です。
キャッシュがフルになると、verbose サブオプションを使用して、JVM のコマンド行にメッセージが出力されます。その後、フルのキャッシュを共用しているすべての JVM が、さらにクラスをプロセス・メモリーにロードします。フルのキャッシュ内のクラスは、依然として共用可能ですが、 フルのキャッシュは読み取り専用で、新しいクラスで更新することはできません。
クラス・データ共用は、類似したコードを実行する複数の JVM を使用するシステムで特に有効です。 このようなシステムには、仮想メモリー使用量を削減できるという利点があります。 また、JVM の始動とシャットダウンを頻繁に行うシステムでも有用で、起動時間を改善することができます。
新しいキャッシュの作成とデータ取り込みのオーバーヘッドは、わずかです。 1 つの JVM の JVM 起動時間は通常、ロードするクラスの数に応じて、クラス・データ共用を使用しないシステムと比べて 0 から 5 % 遅くなります。データ取り込み済みのキャッシュを使用した JVM 起動時間は、 オペレーティング・システムとロードされるクラスの数に応じて、クラス・データ共用を使用しないシステムと比べて通常 10 % から 40 % 向上します。 複数の JVM が並行して稼働する場合、全体の起動時間がさらに大きく向上します。
重複クラスは、共用クラス・キャッシュ内で統合されます。例えば、myClasses.jar からロードされたクラス A と myOtherClasses.jar からロードされたクラス A (同じ内容) は、キャッシュに一度のみ保管されます。printAllStats ユーティリティーは、 重複したクラスの複数の項目を示します。各項目は同じクラスを指します。
クラス・データ共用によりアプリケーションを実行する場合、オペレーティング・システム・ツールを使用して、 仮想メモリー使用量の削減を確認することができます。
クラス・データ共用を製品にデプロイする場合と、開発環境でクラス・データ共用を使用する場合に検討すべき事項を示します。
理論上の最大キャッシュ・サイズは 2 GB です。指定できるキャッシュのサイズは、使用可能なディスク・スペースおよび使用可能な仮想アドレス・スペースの量によって制限されます。
キャッシュは、以下の要因によって制限されます。
バイトコード・データを変更可能な JVM Tool Interface (JVMTI) エージェントを使用する JVM で、変更されたクラスを別の JVM と共用する場合は、modified=<modified_context> サブオプションを使用してください。
modified context (変更コンテキスト) は、実行される変更のタイプを記述する、ユーザー指定の記述子です。 変更コンテキストはキャッシュを区分し、同じコンテキストで実行されるすべての JVM が 1 つの区分を共用できるようにします。
この区分化により、変更されたバイトコードを使用しない JVM は、変更されたバイトコードを使用する JVM との間で 1 つのキャッシュを安全に共用することができます。指定された変更コンテキストを使用するすべての JVM は、予測可能であり反復可能な方法でクラスごとにバイトコードを変更することにより、 キャッシュに保管された変更クラスが別の JVM によってロードされるときに、期待どおりの変更値を持つようにする必要があります。共用クラス・キャッシュからロードされたクラスはエージェントによって再度変更されることはないため、変更は必ず予測可能です。
変更コンテキストなしで JVMTI エージェントを使用する場合も、JVM によりクラスを安全に共用できますが、パフォーマンスに若干の影響が出ます。 JVMTI エージェントで変更コンテキストを使用すれば、余分のチェックが不要になるため、パフォーマンスに影響はありません。java.net.URLClassLoader を拡張し、JVMTI を使用しないでロード時にバイトコードを変更するカスタム ClassLoader は、その変更されたバイトコードを自動的に保管しますが、キャッシュはそのバイトコードを変更されたものとして処理しません。同じキャッシュを共用するその他の VM は、変更されたクラスをロードします。JVMTI エージェントの場合と同じ方法で modified=<modification_context> サブオプションを使用して、キャッシュ内の変更されたバイトコードを区分できます。カスタムの ClassLoader で、クラスに対して予測不能なロード時変更を行う必要がある場合は、その ClassLoader でクラス・データの共用を試行してはいけません。
このトピックについて詳しくは、「Diagnostics Guide (英語)」を参照してください。
32 ビット JVM と 64 ビット JVM の間ではクラスを共用できません。キャッシュ情報を格納できる一時ディスク・スペースが必要です。キャッシュへのアクセス権限は、オペレーティング・システムによって施行されます。
32 ビット・アプリケーションと 64 ビット・アプリケーションの両方を実行できるオペレーティング・システムの場合、 32 ビット JVM と 64 ビット JVM の間でのクラス・データ共用は許可されません。 listAllCaches サブオプションには、使用されている JVM のアドレス・モードに応じて、 32 ビットのキャッシュか 64 ビットのキャッシュがリストされます。
共用クラス・キャッシュは、 システムに存在するキャッシュに関する識別情報を保管するためのディスク・スペースを必要とします。 この情報は、ユーザー・プロファイル・ディレクトリーに置かれます。 識別情報ディレクトリーが削除された場合、JVM はシステム上の共用クラスを識別できないため、 キャッシュを再作成する必要があります。
共用クラス・キャッシュにアクセスするための許可は、オペレーティング・システムによって執行されます。キャッシュ名が指定されない場合、 同じシステム上の複数のユーザーがデフォルトで独自のキャッシュを作成するように、 デフォルト名にユーザー名が付加されます。
クラス・データ共用と併せて SecurityManager が使用され、 稼働中のアプリケーションで独自のクラス・ローダーが使用されている場合、 クラスを共用する前に、これらのクラス・ローダーにクラス共用の許可を付与する必要があります。
ClassLoader クラス名 (ワイルドカードを使用可) と、付与するアクセス権を決定する "read"、"write"、または "read,write" のいずれかを使用して、java.policy ファイルに共用クラスのアクセス権を追加します。 例えば、次のようにします。
permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";ClassLoader
に正しいアクセス権が設定されていないと、ClassLoader はクラスを共用できません。デフォルトのブートストラップ、アプリケーション、または拡張クラス・ローダーの許可は、変更できません。
java.net.URLClassLoader を拡張するクラス・ローダーは、変更することなくクラスを共用できます。java.net.URLClassLoader を拡張しないクラス・ローダーは、クラス・データを共用するように適応させる必要があります。
SecurityManager が使用される場合、すべてのカスタム・クラス・ローダーに、クラス共用の許可が付与される必要があります。SharedClassPermission の使用を参照してください。IBM は、カスタム・クラス・ローダーのさまざまなタイプに応じたいくつかの Java インターフェースを提供しています。 これにより、そのクラス・ローダーが、共用クラス・キャッシュでクラスを検出および保管することができます。これらのクラスは、com.ibm.oti.shared パッケージにあります。
このパッケージの Javadoc は、SDK で docs/content/apidoc ディレクトリーに提供されます。
これらのインターフェースの使用方法について詳しくは、「Diagnostics Guide (英語)」を参照してください。
Java Communications (API) パッケージ (JavaComm) は、Runtime Environment for Windows で使用するために提供されているオプションのパッケージです。 JavaComm は、SDK あるいは Runtime Environment とは別に単独でインストールします。
JavaComm API により Java アプリケーションは、 ボイス・メール、ファクシミリ、およびスマートカードなどのテクノロジーに シリアルおよびパラレル・ポート通信を、プラットフォームに依存しないで実施することができます。
Java Communications API は、Electronic Industries Association (EIA)-232 (RS232) シリアル・ポートと米国電気電子学会 (IEEE) 1284 パラレル・ポートをサポートし、また、 IBM バージョン 6 Runtime Environment の入ったシステムに対応しています。
Java Communications API を使用すると、以下のことが行えます。
Java Communications API をインストールする前に、SDK または Runtime Environment がインストール済みであることを確認してください。
Java Communications API を圧縮ファイルからインストールするには、以下のようにします。
javax.comm.properties ファイルによって、Java Communications API で使用可能にするデバイスの接頭部および、それらのデバイスがパラレルかシリアルかを指定することが可能です。ポート番号は、すべてのデバイスに順に割り振られます。
例えば、/dev/ttyS=PORT_SERIAL と指定して、2 つのデバイス、/dev/ttyS0 および /dev/ttyS1 が存在する場合、それらのデバイスは、COM1 および COM2 に割り振られます。
USB-シリアル・コネクターを使用する場合は、javax.comm.properties ファイルの /dev/ttyUSB=PORT_SERIAL 行のコメントを外します。デバイス /dev/ttyUSB0 および /dev/ttyUSB1 が存在するが、すでに COM1 および COM2 が定義済みの場合、これらの USB-シリアル・デバイスは COM3 および COM4 に割り振られます。
Java Communications API を使用して印刷をするときは、プリンターで「用紙送り」、「継続」、または類似したボタンを押す必要があります。
Java Communications API をアンインストールするには、Runtime Environment をインストールしたディレクトリーから以下のファイルを削除します。
Runtime Environment は、デフォルトで C:¥Program Files¥IBM¥Java60¥ ディレクトリーにインストールされます。
API ドキュメンテーションと Java Communications API のサンプルは、次の Sun Web サイトで参照できます。
http://java.sun.com/products/javacomm/
サービスの連絡先:
IBM Solutions Developer Program に準ずるプログラム・コードのサービスを受けられる場合、 通常の利用方法によって、または Web (http://www.ibm.com/partnerworld/) で IBM Solutions Developer Program にお問い合わせください。
サービス契約 (つまり、IBM の Personal Systems Support Line または各国における同等サービス) を購入している場合は、 そのサービス契約の条件によって、そのプログラムに関して受けられるサービス (該当がある場合) が決まります。
この SDK および Runtime Environment で提供されるこのユーザー・ガイドは、スクリーン・リーダーを使用してテストしてあります。
ユーザー・ガイドのフォント・サイズを変更するには、ご使用のブラウザーで提供される機能を使用して ください。通常、「表示」メニュー・オプションにあります。
キーボード・ナビゲーションが必要な場合は、http://www.ibm.com/developerworks/java/jdk/additional/ の『Swing Key Bindings』にある Swing アプリケーション用の便利なキー・ストロークの説明を参照してください。
カーソル・キーを使用して JComboBox コンポーネントのドロップダウン・リストを上下に探索する場合、実際に項目が選択されるまで JComboBox のボタンあるいは編集可能フィールドは変更されません。これは、このリリースで正しい動作で、キーボードによる探索動作とマウスによる探索動作の 一貫性が保たれるため、アクセス可能度や使用可能度が向上します。
Version 5.0 以降では、Java Web Start にはアクセス可能度と使用可能度において種々の改善がなされて、例えば、スクリーン・リーダーのサポートが充実し、キーボード・ナビゲーションも改善されています。
コマンド行のみで、Web Start 用に使用可能になっている Java アプリケーションを起動することができます。設定オプションを変更するには、ユーザーのホーム・ディレクトリーにある構成ファイル Application Data¥IBM¥Java¥Deployment¥deployment.properties を編集する必要があります。このファイルは、編集する前にバックアップをとってください。 Java アプリケーション・キャッシュ・ビューアーで指定できる設定がすべて、構成ファイルにあるわけではありません。
JCE 無制限管轄ポリシー・ファイルは、http://www.ibm.com/developerworks/java/jdk/security/index.html から入手できます。 IBM セキュリティー・パッケージ JCE、JCEFIPS、JSSE2、JSSEFIPS、JGSS、JAAS、およびハードウェア暗号方式に関する文書も、 この Web サイトで入手できます。
本書に関するご意見は、以下の連絡手段のいずれかを使用してご連絡ください。なお、これらの連絡手段は、技術的な問い合わせに答えるためではなく、資料に対するご意見のみをお聞きするために設けてあることを、ご了承ください。
ご意見の送り先は次のとおりです。
ただし、IBM にメッセージを送る際には、フィードバック・データ (質問、意見、提案事項な ど) を含め、メッセージに組み込む情報はすべて公表を承諾されたものとみなされる こと、IBM ではこれらの情報をいかなる義務も負うことなく、無制限にコピー、利用、開示し、かつ他に対して配布できることをご承知おきください。さらに、IBM では、 これらの情報に含まれるすべての着想、概念、ノウハウ、または技術を、製品の開発、 製造、および販売など、あらゆる目的に利用できるものとします。
以下にリストする -X オプションは非標準であり、予告なしに変更されることがあります。
<size> パラメーターを取るオプションでは、その数値の後に、キロバイトを示す「k」または「K」、メガバイトを示す「m」または「M」、あるいはギガバイトを示す「g」または「G」を付け加えてください。
<percentage> パラメーターをとるオプションでは、0 から 1 までの数値を使用します。例えば、50% は 0.5 となります。
指定されたファイルに詳細ガーベッジ・コレクション (GC) 出力を書き出します。ファイルがすでに存在していると、上書きされます。それ以外の場合で、既存ファイルを開けないか、新しいファイルを作成できない場合は、出力は stderr にリダイレクトされます。引数 X および Y (両方とも整数) を指定すると、 詳細 GC 出力は X 個のファイルにリダイレクトされ、各ファイルには Y 個の gc サイクルの詳細 GC 出力が含まれます。これらのファイルは、filename1、filename2、... という形式になります。デフォルトでは、詳細 GC ロギングは行われません。
詳細 GC 出力について詳しくは、「Diagnostics Guide (英語)」を参照してください。
SDK および Runtime Environment for Windows の既知の制限。
問題の診断方法について詳しくは、「Diagnostics Guide (英語)」(http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html) を参照してください。
IBM 32-bit SDK for Windows, v6 は、以下のロケールをサポートします。
ただし、これらのロケールのフォントは、AWT コンポーネントでは機能しない可能性があります。
IBM 32-bit SDK for Windows, v6 は、IPv6 をサポートします。ただし、現在の Windowsにおける IPv6 のサポートはデュアル・スタックではないため、SDK は、IPv6 対応システムでデュアル・スタックの動作をエミュレートします。ご使用の Java アプリケーションは、エミュレーションの性質から、最大 2 倍の数のソケットを使用する可能性があります。 このエミュレーションを使用不可にするには、システム・プロパティー java.net.preferIPv4Stack を true に設定して SDK の IPv6 サポートを使用不可にしてください。
IBM の JConsole ツールでは、同じシステム上の他の仮想マシンに接続できるようにするための「ローカル (Local)」タブを使用できません。 また、対応するコマンド行である pid オプションもサポートされていません。代わりに、JConsole の「リモート (Remote)」タブを使用して、モニター対象の仮想マシンに接続してください。あるいは、connection コマンド行オプションを使用して、ホスト localhost とポート番号を指定します。モニターするアプリケーションを起動するときに、次のコマンド行オプションを設定します。
Mozilla Rhino Javascript エンジンは、ライセンス交付の問題があるため、IBM SDK for Java には組み込まれていません。IBM SDK for Java で Rhino Javascript エンジンを使用するには、https://scripting.dev.java.net/ から jsr223 スクリプト・エンジンをダウンロードし、Mozilla Web サイト (http://www.mozilla.org/rhino/) から Rhino Javascript エンジンをダウンロードしてください。
IME を使って作業をしている時は、スクリーン上のワークスペースで漢字入力以外の操作をする前に、漢字入力と候補の選択を終わらせておくようにお勧めします。
IME を使用して AWT TextArea 内にテキストを入力する場合、 そのテキストを確定する前 にアプリケーションのウィンドウをサイズ変更すると、 そのテキストは自動的に確定されます。
一般的でない長さの DSA 鍵ペアの作成は、低速なマシンでは非常に長い時間を要します。 十分な時間が経過すれば完了するので、遅れてもハングしたと解釈しないでください。DSA 鍵生成アルゴリズムは、標準の鍵の長さ (例えば、512、1024) を他より迅速に生成するよう、最適化されています。
パーソナル・ファイアウォールが原因で、 Windows NIO コードに問題が生じ、その結果、特定の操作が失敗することがあります。例えば、メソッド呼び出しの Selector.open() は、「java.io.IOException: ループバック接続を確立できません (java.io.IOException: Unable to establish loopback connection)」をスローし、「java.net.ConnectException: 接続が拒否されました: connect (java.net.ConnectException: Connection refused: connect)」の原因になります。この例外は、ファイアウォールでブロックされているポートに接続する オペレーティング・システムによって起こります。 JVM は、オペレーティング・システムに別のポート番号を選択するように要求して、 接続操作を再試行します。 何度か再試行しても接続できない場合は、ConnectException がスローされます。
この例外が発生したら、システム・プロパティー java.nio.debug=pipe を設定して、どのポート番号がブロックされているかを確認してください。
Windows 2000 および XP では、同時にオープンできるファイル数のデフォルト値が小さすぎるため、入出力集中のアプリケーションで問題が起こります。 この制限を修正するには、ファイル <windows>¥system32¥CONFIG.NT を編集し、以下の値を設定します。
files=200 buffers=60
ここで、<windows> は Windows がインストールされたディレクトリーです。
Windows 2000 において、32 ビット・カラー階調で、JVM の DirectDraw メカニズムが、マウス・ポインターの下の領域を再描画しません。その結果として、メニュー上にマウスがあった後、そこにグレーまたは黒の正方形が表示されます。 次善策としては、ダイレクト・ドローをオフに切り替える (-Dsun.java2d.noddraw) か、または画面カラー解像度を他の値 (256 色など) に変更します。
NIO SocketChannel finishConnect() 呼び出しは、true (チャネルが接続された) または false (接続処理が未完了) を戻すか、例外をスローする可能性があります。 Windows 2000 で非ブロッキング接続を使用する場合、前の Java select() 呼び出しでチャネルでの処理準備が完了していることが示された後でも、FALSE が戻される可能性があります。
Java メイン・スレッド (原始スレッドとも呼ばれる) のスタック範囲は、 実行時に変更できません。メイン・スレッドのサイズは、256 KB の固定で、これはパフォーマンス上の理由から最適な値として判断されたものです。 -Xss オプションを使用すると、 メイン・スレッド以外のスレッドについてのみ、スタック範囲を変更できます。 メイン・スレッドは、他のスレッドよりスタック・オーバーフローが発生しやすいため、過重な再帰的計算があるプログラムには使用しないでください。
JTextArea、JTextField、または JFileChooser に DBCS 文字を入力中に、一部の中国語 IME (特に、Chinese Internal Code および Zhengma) から Intelligent ABC IME に切り替えると、メモリー・ダンプが生成される場合があります。
チェコ語ユーザーの場合、InstallShield の言語選択パネルで、 本来なら翻訳されないインストールにおいて、翻訳された 1 つの項目が示されます。この制限は InstallShield に起因するものです。このストリングは、コード・ページに基づいてオペレーティング・システムから取得されます。 ポーランド語 (インストールが翻訳される) とチェコ語のコード・ページは両方とも 1250 であるため、 InstallShield は、両方の言語についてシステムから言語リストを取得しようとするため、 このストリングが言語リストに入ります。
中国語 (繁体字) を使用する場合、Java アプリケーションからの出力を直接 more コマンドにパイプ接続しないでください。代わりに、その出力を一時ファイルに送って、そのファイルを別に表示してください。
カタロニア語ユーザーの場合、アクセント記号付きの大文字が破壊されないようにするために、 Lucida Console フォントを使用してください。 これが影響するのは、Windows 2000 のユーザーのみです。
DBCS 環境のみ
ご使用のアプリケーションで GTK Look and Feel を使用していて NullPointerException の障害が発生する場合、GNOME_DESKTOP_SESSION_ID 環境変数を設定解除してください。
日本語ユーザーのみ
Shift_JIS の Unicode コード・ページ別名 「¥u30b7¥u30d5¥u30c8¥u7b26¥u53f7¥u5316¥u8868¥u73fe」は削除されています。アプリケーションでこのコード・ページを使用する場合は、Shift_JIS で置き換えてください。
本書は米国 IBM が提供する製品およびサービスについて作成したものです。 本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。
本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む)を保有している場合があります。本書の提供は、お客様にこれらの特許権について 実施権を許諾することを意味するものではありません。 実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
以下の保証は、国または地域の法律に沿わない場合は、適用されません。
IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、 商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、 便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものでは ありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部では ありません。それらの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムと その他のプログラム(本プログラムを含む)との間での情報交換、 および (ii) 交換された情報の相互利用を可能にすることを目的として、 本プログラムに関する情報を必要とする方は、下記に連絡してください。
本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で 決定されたものです。 そのため、他の操作環境で得られた結果は、異なる可能性があります。 一部の測定が、開発レベルのシステムで行われた可能性がありますが、 その測定値が、一般に利用可能なシステムのものと同じである保証はありません。 さらに、一部の測定値が、推定値である可能性があります。 実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
IBM、AIX、developerWorks、eServer、iSeries、MVS、POWER4、 POWER5+、 PowerPC、pSeries、System i、System p、System z、WebSphere、System z9、z/OS、および zSeries は、International Business Machines Corporation の米国およびその他の国における商標です。
Intel は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。
Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。
Microsoft、Windows および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。