注: 本書および本書で紹介する製品をご使用になる前に、『特記事項』に記載されている情報をお読みください。
本書は、IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition Version 5.0、および新しい版で明記されていない限り、 以降のすべてのリリースおよびモディフィケーションに適用されます。
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
(c) Copyright International Business Machines Corporation, 1999, 2005. All rights reserved.
(c) Copyright IBM Japan 2005
本書には、IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition Version 5.0 の概説と、 Sun の実装と対比した IBM の実装の相違点に関する具体的な情報が記載されています。 本書は、Sun の Web サイト (http://java.sun.com) の詳細な資料と一緒にお読みください。
SDK および Runtime Environment は、次の製品でサポートされています。
IPv6 は Windows XP および Windows Server 2003 でのみサポートされています。
IBM Virtual Machine for Java について詳しくは、 「Diagnostics Guide (英語)」を参照してください。
本書の Version 5.0 での技術的な変更は、小さな変更や明らかな変更 (「1.4.2」を「5.0」に書き換えた、など) を除き、 HTML やカラー印刷コピーでは赤で示され、また、変更個所の左側に縦線が示されています。
用語「Runtime Environment」と「Java 仮想マシン」は、本書を通じて読み替えることができます。
IBM SDK は、IBM Java 5.0 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 v5.0 でも正しく動作します。 このリリースでコンパイルしたクラスの、前のリリースでの動作については保証できません。
|IBM 32-bit SDK for Windows V5.0 は、Microsoft Visual Studio .NET 2003 を使用して |作成されました。
互換性に関して Sun のドキュメンテーションを読む場合は、Sun の Web サイト http://java.sun.com を参照してください。
前のリリースから SDK をアップグレードする場合は、アップグレードを進める前に、 すべての構成ファイルおよびセキュリティー・ポリシー・ファイルをバックアップしてください。
これらのファイルはアップグレード処理中に上書きされた可能性があるため、 アップグレードの後に、それらのリストアまたは再構成が必要な場合があります。 ファイルのフォーマットやオプションが変わった可能性があるため、 元のファイルをリストアする前に、新しいファイルの構文を確認してください。
Version 5.0 では、IBM Runtime Environment for Windows に、新しいバージョンの IBM Java Virtual Machine と 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、および付随するライセンス、著作権ファイル、デモ・ディレクトリーのみです。 Sun の Web サイトにアクセスして Sun のソフトウェア・ドキュメンテーションを表示するか、 あるいは、Sun の Web サイト http://java.sun.com から Sun の ソフトウェア・ドキュメンテーション・パッケージをダウンロードすることができます。
SDK または Runtime Environment パッケージをインストールするには、 関連のインストール・パッケージをダウンロードします。 必ず、すべてのパッケージを同じディレクトリーにダウンロードしてください。 パッケージとそのファイル名は『手動 (対話式) インストール』にリストされています。 パッケージのファイル名は変更しないでください。
インストールを開始する前に、C:¥WINDOWS¥TEMP ディレクトリーに、インストール中に使用する十分なスペースがあることを確認してください。 インストール中に TEMP ディレクトリーで必要な一時スペースの量は、以下のとおりです。
一時スペースが十分にない場合、インストール・プログラムはエラーを生成し、インストールを終了します。 一時スペースが十分にあるのに、このメッセージが表示される場合は、 インストールしようとしているパッケージが完全にダウンロードされていることを確認してください。 これを行うには、手元のパッケージのファイル・サイズを、そのダウンロード元の Web ページに表示されているファイル・サイズと比較します。
インストールできるパッケージは、以下のとおりです。
他のパッケージは zip ファイルで提供されます。
Runtime Environment はデフォルトでディレクトリー C:¥Program Files¥IBM¥Java50¥jre にインストールされます。
SDK インストール可能パッケージをダウンロードした場合、以下をインストールするかどうかを選択できます。
コンポーネントは、個別にインストールすることも、組み合わせてインストールすることも可能です。
インストール・ウィザードでは、以下のオプションが示されます。
Runtime Environment を (SDK インストール可能パッケージの一部として、または Runtime Environment インストール可能パッケージから) インストールする際、 Runtime Environment をシステム Java 仮想マシン (JVM) としてインストールするかどうかを尋ねられます。 それをシステム JVM としてインストールする場合、インストール・プログラムは、 java.exe および javaw.exe ファイルを Windows システム・ディレクトリーにコピーします。 あるバージョンの java.exe または javaw.exe が Windows システム・ディレクトリーに現存すると、 現行バージョンで既存バージョンを上書きするプロンプトが出されます。 これらのファイルを Windows システム・ディレクトリーにインストールすると、 この Runtime Environment がシステムのデフォルト JVM になります。 さらに、「Current Version」レジストリー・キーが、このインストールに適合するように設定されます。
自動インストールを作成する場合、最初に手動 (対話式) インストールを完了し、 インストール中に行った選択を記録した応答ファイル (setup.iss) を作成する必要があります。 作成した応答ファイルは、それを使用する予定のコンピューターに応じた適切なものでなければなりません。 必要であれば、構成が異なるコンピューターにパッケージをインストールするために使用する、 複数の応答ファイルを作成します。
インストールの実行中に応答ファイルを作成するには、コマンド・プロンプトで以下を入力します。
ibm-java2-sdk-50-win-i386 /rまたは
ibm-java2-jre-50-win-i386 /r
ご使用の Windows 製品に応じて、応答ファイル (setup.iss) は、 C:¥Windows または C:¥Winnt ディレクトリー (ここで、C: はブート・ドライブ) に作成されます。
対話式インストールの間に、以下のメッセージが発生する場合があります。
別の Java Runtime Environment がシステム JVM として現在インストール済みです。 このバージョンを上書きするには「はい」を、このインストールを終了するには「いいえ」を選択してください。 (Another Java Runtime Environment is currently installed as the System JVM. Select Yes to overwrite this version or No to exit this installation.)
このメッセージが表示されたら、「いいえ」を選択し、インストールを終了します。 Windows システム・ディレクトリーに移動し、以下の 2 つのファイルを削除してください。
ファイルを削除したら、この節の最初に示されたコマンドを使用して、対話式インストールを再始動します。
自動インストールを実行するシステムで、 setup.iss 応答ファイルを C:¥Windows ディレクトリーにコピーします。 ファイルをコピーしたら、コマンド・プロンプトで以下を入力します。
ibm-java2-sdk-50-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log ibm-java2-jre-50-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log
インストールが正常に終了した場合、ログ・ファイルに ResultCode=0 というストリングが含まれます。
IBM Accessibility Bridge はインストールされますが、デフォルトで使用不可になっています。 IBM Accessibility Bridge を使用可能にするには、jre/lib ディレクトリーの Accessibility.properties ファイルにある以下の行で、先頭の番号記号 (#) を削除します。
#assistive_technologies=JawBridge
次の Web サイトに、Accessibility Utilities の詳細があります。
http://java.sun.com/products/jfc/accessibility.html
Java Accessibility サポートを使用不可にすると、Java 支援テクノロジー・サポートを提供しない Java アプリケーションの JVM ロード・パフォーマンスが、特にネットワーク・リンクを介する場合に、向上します。
Java Accessibility サポートを使用不可にするには、JAVA_ASSISTIVE 環境変数を OFF に設定します。JawBridge などの支援テクノロジーは、 この環境変数が OFF に設定されていると、そのテクノロジーが Accessibility.properties ファイルで使用可能にされていても利用できません。
Windows で、プロセスは 2 つのコード・ページを持ちます。それは、ANSI (または Windows) コード・ページと OEM (または DOS) コード・ページです。
コマンド・ウィンドウは通常、OEM コード・ページを使用します。 Java コンソール出力は、Java を開始したコマンド・ウィンドウのコード・ページを使用します。 ただし、javaw コマンドは常に ANSI コード・ページを使用します。 コンソール出力に使用するコード・ページは、 java コマンドの -Dconsole.encoding オプションで指定します。 例えば、-Dconsole.encoding=Cp1252 とすると、 すべてのコンソール出力が Windows ANSI Latin1 コード・ページ (1252) になります。
PATH 環境変数を以下に示すように変更する場合、ご使用のパスにある既存の Java 実行可能ファイルを オーバーライドすることに注意してください。
SDK をインストールした後は、シェル・プロンプトでツールの名前を入力し、 ファイル名を引数に指定して、ツールを使用できます。
ツールへのパスは、その都度、ツール名の前にパスを入力して指定します。 例えば、SDK for Windows が C:¥Program Files¥IBM¥Java50¥bin にインストールされている場合、myfile.java という名前のファイルを コンパイルするには、コマンド・プロンプトで以下のように入力します。
"C:¥Program Files¥IBM¥Java50¥bin¥javac" myfile.java
毎回絶対パスを入力しないで済むようにするには、
SDK または Runtime Environment を別のディレクトリーにインストールした場合、SDK または Runtime Environment をインストールした ディレクトリーで C:¥Program Files¥IBM¥Java50¥ を置き換えてください。
javac myfile.java
PATH 環境変数を指定すると、Windows は、現行ディレクトリーから 実行可能ファイル (javac、java、および javadoc など) を見つけます。 ご使用の PATH の現行値を表示するには、コマンド・プロンプトで次のように入力します。
echo %PATH%
CLASSPATH により、SDK ツール (java、javac、および javadoc など) は Java クラス・ライブラリーがある場所がわかります。
以下のいずれかが該当する場合のみ、CLASSPATH を明示的に設定する必要があります。
ご使用の CLASSPATH の現行値を表示するには、 コマンド・プロンプトで、次のように入力します。
echo %CLASSPATH%
別にインストール済みの他のバージョンも含めて、 異なるランタイム環境を使用する複数のアプリケーションを作成し実行する予定の場合、 CLASSPATH (および PATH) をそれぞれのアプリケーションごとに明示的に設定する必要があります。複数アプリケーションを 同時に実行し、異なるランタイム環境を使用する予定の場合、それぞれのアプリケーションが固有の コマンド・ウィンドウで実行される必要があります。
一度に 1 つのバージョンの Java のみ実行する場合は、 バッチ・スクリプトを使用して、異なる ランタイム環境を切り替えることができます。
SDK をアンインストールするには、自動インストールでも手動 (対話式) インストールでも、以下のようにします。
この手順により、インストーラーでインストールされたパッケージはすべて除去されます。これでは、Java Communications API パッケージ (Java Communications API を参照) と、zip パッケージから 解凍されたその他のファイルは、除去されません。
IBM 32-bit SDK for Windows v5.0 と バージョン V1.3.1 以前のものを複数インストールして保守してきた環境で、 バージョン V5.0 がまだシステムにインストールされている間に以前のバージョンを アンインストールすると V1.3.1 アンインストーラーは V5.0 バージョンで必要である、 以下のレジストリー・キー、およびすべてのサブキーを除去してしまいます。その結果、V5.0 のインストール済み環境を壊してしまいます。
そこで、V1.3.1 バージョンをアンインストールしてから、バージョン V5.0 を 再インストールしてください。 このアンインストーラーの制限事項は、V1.4.0 以降のリリースでは修正されています。
java ツールは、Java Runtime Environment を開始し、指定されたクラスをロードすることによって、 Java アプリケーションを起動します。
JVM は、初期クラス (および使用されるその他のクラス) を、ブートストラップ・クラスパス、 インストールされた拡張機能、ユーザー・クラスパスの 3 カ所で検索します。 クラス名または JAR ファイル名の後に指定する引数が、main 関数に渡されます。
javaw コマンドは、javaw には関連するコンソール・ウィンドウがないことを除いて、java と同一です。 コマンド・プロンプト・ウィンドウを表示したくない場合には javaw を使用してください。 javaw ランチャーは、起動に失敗した場合に、エラー情報を含むダイアログ・ボックスを表示します。
java および javaw コマンドの構文は次のとおりです。
java [ options ] class [ arguments ... ] java [ options ] -jar file.jar [ arguments ... ] javaw [ options ] class [ arguments ... ] javaw [ options ] -jar file.jar [ arguments ... ]
大括弧で囲まれている項目はオプショナルです。
-jar オプションが指定された場合には、指定された JAR ファイルにアプリケーションのクラスおよびリソース・ファイルが入っていて、始動クラスは Main-Class マニフェスト・ヘッダーで示されています。
ランチャーには、現在の Runtime Environment でサポートされ、将来のリリースでサポートされる標準オプションのセットがあります。 このほかに、非標準オプションのセットがあります。 デフォルト・オプションは、最も一般的な使用法に応じて選択されています。 変更する場合には注意してください。
Java オプションおよびシステム・プロパティーを指定するには、3 つの方法があります。 それらは、優先順に以下のものです。
コマンド行では、右端のオプションが左端のオプションより優位になります。 例えば、「-Xint -Xjit myClass」というオプションを指定した場合、 -Xjit が優位になります。
以下にリストする -X オプションは非標準であり、予告なしに変更されることがあります。
<size> パラメーターを取るオプションでは、 その数値の後に、キロバイトを示す「k」または「K」、メガバイトを示す「m」または「M」、 あるいはギガバイトを示す「g」または「G」を付け加えてください。
IBM ビルド番号およびバージョン番号を確認するには、コマンド・プロンプトで以下を入力してください。
java -version
java コマンドやその他の java ランチャー・コマンド (javaw など) では、クラス名を現行ロケールの文字セット内の任意の文字で指定できます。
また、Java エスケープ・シーケンスを使用して、クラス名と引数に任意の Unicode 文字を指定することもできます。 これを行うには、-Xargencoding を指定する必要があります。 Unicode 文字を指定するには、エスケープ・シーケンスを ¥u#### の形式で使用します。ここで # は 16 進数字 (0 から 9、A から F) です。
あるいは、クラス名およびコマンド引数が UTF8 エンコード方式であることを指定するには -Xargencoding:utf8 を、ISO8859_1 エンコード方式であることを指定するには -Xargencoding:latin を使用します。
例えば、「HelloWorld」というクラスを 2 つの大文字について Unicode エンコード方式を使用して指定する場合、 次のコマンドを使用します。
java -Xargencoding '¥u0048ello¥u0057orld'
java および javaw コマンドは、 翻訳された出力メッセージを示します。これらのメッセージは、Java が稼働しているロケールに基づいて異なります。 エラーの詳細説明や、java が戻すその他のデバッグ情報は、英語で表示されます。
java クラスまたは JAR ファイルをファイルから自動的に実行するように設定するには、Windows のエクスプローラの 「ツール」->「フォルダ オプション」->「ファイルの種類」オプションを使用します。あるいは、コマンド・プロンプトから次のように入力します。
assoc .class=javaclass ftype javaclass=C:¥Program Files¥IBM¥Java50¥jre¥bin¥java.exe %l %*
Sun では、スクリーン・リーダー、Java アプリケーションにおける Java アクセシビリティ・サポートへのアクセスなど、ネイティブ 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/index.jsp
IBM Just-In-Time (JIT) コンパイラーは、Java アプリケーションやアプレットで実行中に頻繁に使用される バイトコード・シーケンスのマシン・コードを動的に生成します。 |JIT V5.0 コンパイラーは、コンパイラーの研究によって新しい最適化を実現し、 |前のバージョンの JIT に実装されていた最適化を改良して、ハードウェアをより大きく活用しています。
IBM SDK and Runtime Environment には JIT が含まれており、SDK ツールのほかユーザー・アプリケーションにおいても、 デフォルトで使用可能に設定されています。 通常、明示的に JIT を起動する必要はありません。 Java バイトコードからマシン・コードへのコンパイルは、透過的に行われます。 ただし、Java アプリケーションまたはアプレットを実行中に Runtime Environment で問題が発生した場合には、問題の切り分けのために JIT を使用不可にすることができます。 JIT を使用不可にするのは、一時的な手段のみにしてください。 JIT は、適切なパフォーマンスを得るために必要です。
JIT を使用不可にするには 3 つの方法があります。
アプリケーションが実行されるコマンド・プロンプトで、以下を入力します。
set JAVA_COMPILER=NONE
また、グラフィカル・ユーザー・インターフェースを使用して、JAVA_COMPILER を 恒久的に設定することもできます。 「コントロール パネル」を開いて「システム」を選択し、 「詳細」タブで「環境変数」を選択します。
java -Djava.compiler=NONE MyApp
java -Xint MyApp
どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。
明示的に JIT を使用可能にするには、JAVA_COMPILER 環境変数に "jitc" を設定するか、または、-D オプションを使用して java.compiler プロパティーに "jitc" を設定します。 あるいは、JVM コマンド行で -Xjit オプションを使用 (かつ -Xint オプションは省略) して JIT をオンにします。
JAVA_COMPILER 環境変数または java.compiler プロパティーに "" (空ストリング) が設定されている場合、 JIT は使用不可のままになります。 環境変数を適切に設定解除するには、 コマンド・プロンプトで set JAVA_COMPILER= を入力します。
JIT が使用可能かどうかを判別するには、コマンド・プロンプトで次のように入力します。
java -version
JIT が使用できない場合には、以下の内容のメッセージが表示されます。
(JIT disabled)
JIT が使用できる場合には、以下の内容のメッセージが表示されます。
(JIT enabled)
JIT についての詳細は、「Diagnostics Guide (英語)」を参照してください。
ガーベッジ・コレクターは、Java が使用するメモリーおよび VM 内で稼働するアプリケーションが使用するメモリーを管理します。
ガーベッジ・コレクターはストレージの要求を受け取ると、ヒープ内の未使用メモリーを引き当てます。すなわち、 「割り振り」です。 また、ガーベッジ・コレクターは、もはや参照されていないメモリー領域を確認し、それらを再利用のために 解放します。これがすなわち「コレクション」です。
コレクション・フェーズは、メモリーの割り振り障害がトリガーとなって起動されます。割り振り障害は、 ストレージ要求に対してスペースが残っていない場合に発生するか、または、明示的な System.gc() 呼び出しによっても 引き起こされます。
ガーベッジ・コレクションは、アプリケーションのパフォーマンスに大きく影響するので、 IBM 仮想マシンは、ガーベッジ・コレクション実行の方法を最適化するためにさまざまな メソッドを提供して、アプリケーションへの影響を削減するようにしています。
ガーベッジ・コレクションに関する詳細情報は、「Diagnostics Guide (英語)」を参照してください。
-Xgcpolicy オプションは、ガーベッジ・コレクション・ポリシーを指定します。
-Xgcpolicy は、値として optthruput (デフォルトおよび推奨値)、optavgpause、または gencon を使用します。このオプションは、 ガーベッジ・コレクターの動作を制御して、アプリケーションおよびシステム全体のスループットと ガーベッジ・コレクションに起因する休止時間とのトレードオフを図ります。
このオプションのフォーマットと値は次のとおりです。
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
アプリケーションがオブジェクトを作成しようとして、その要求がヒープ内の使用可能スペースの理由で すぐに実現しない場合に、ガーベッジ・コレクターは、参照されていないオブジェクト (ガーベッジ) を 識別してそれらを削除し、ヒープの状態を即時および後続の割り振り要求にすぐに応じられる状態に 戻す責任があります。 そうしたガーベッジ・コレクションの繰り返しにより、アプリケーション・コードの実行時に 予期しない休止が時々起こることがあります。アプリケーションは大きく複雑になってきており、 ヒープもそれに応じて大規模になっているので、 このガーベッジ・コレクション休止時間は長さも重要度も増す傾向にあります。デフォルトの ガーベッジ・コレクション値の -Xgcpolicy:optthruput では、 非常に高いスループットがアプリケーションにもたらされますが、 こうした一時休止 (ヒープ・サイズとガーベッジの質により数ミリ秒からかなりの秒数まであり得る) が 代償になっています。
JVM は、一時休止時間を削減するために 2 つの手法を使用します。
-Xgcpolicy:optavgpause コマンド行オプションは、並行ガーベッジ・コレクションの 使用を要求し、ガーベッジ・コレクションの一時休止にあてられる時間を大幅に削減します。 並行ガーベッジ・コレクション (GC) は、一部のガーベッジ・コレクション・アクティビティーを 通常のプログラム実行と並行して行うことにより、ヒープのコレクションが原因で起きる中断を最小限に して、一時休止時間の削減を図ります。 また、-Xgcpolicy:optavgpause オプションは、ヒープ・サイズの増加が ガーベッジ・コレクション休止の長さに与える影響を制限します。 -Xgcpolicy:optavgpause オプションは、大容量のヒープを抱える構成の場合に 非常に有効です。 休止時間を削減することによって、アプリケーションのスループットがある程度縮小される場合があります。
並行ガーベッジ・コレクション時に、比較的長く存続していて収集できないオブジェクトの識別に かなりの時間が無駄に使われています。 GC が、リサイクル可能な傾向のあるオブジェクトのみに集中すれば、一部のアプリケーションへの 一時休止時間をさらに削減することができます。世代別 GC は、ヒープを 2 つの「世代」、すなわち、 「新しい世代」と「古い世代」の領域に分けることでこれを実現します。 オブジェクトはその経過時間によって、この領域のどちらかに入れられます。 新しい世代領域は、2 領域の小さい方で、若いオブジェクトが入ります。一方、古い世代領域は、 大きい方で、古いオブジェクトが入ります。オブジェクトは、まず、新しい世代領域に割り振られて、 長期間存続した場合に、最終的に古い世代領域にレベル上げされます。
世代別 GC は、長期間存続しない多くのオブジェクトに依存しています。世代別 GC は、 多くのリサイクル可能なスペースを保有する、新しい世代領域のストレージを再利用することに 活動を集中させて、一時休止時間を削減します。 ヒープ全体をコレクションするために時折でも長い休止時間をとるのではなく、新しい世代を より頻繁に収集するので、新しい世代領域が小さければ、休止時間も比較的短くなります。 しかし、世代別 GC は、時間が経過すると存続期間が長いオブジェクトが非常に多くなり 古い世代領域が満杯になる可能性があるという欠点があります。 そうした状態が発生したときに一時休止時間を最小限にするために、並行 GC と世代別 GC を組み合わせて 使用してください。 -Xgcpolicy:gencon オプションで、ガーベッジ・コレクションの一時休止の時間を 最小限にするために、並行 GC と世代別 GC を組み合わせて使用することを要求します。
Java ヒープが満杯に近く、再利用できるガーベッジが少ししかない場合、即時使用可能なスペースがないため、新規オブジェクト用の要求がすぐには満たされないことがあります。ヒープが容量いっぱいに近い状態で操作されている場合、上記オプションのどちらが使用されているのかに関係なく、アプリケーション・パフォーマンスは悪くなります。 また、さらにヒープ・スペースの要求が続けば、アプリケーションはメモリー不足例外を受け取り、その例外がキャッチされ処理されなければ、JVM は終了します。この時点で、 JVM は、javadump 診断ファイルを生成します。このような状態の場合、-Xmx オプションを使用してヒープ・サイズを増やすか、 使用中のアプリケーション・オブジェクトの数を減らすことをお勧めします。詳しくは、「Diagnostics Guide (英語)」を参照してください。
JVM に関係のあるシグナルが生じると、シグナル・ハンドラーが呼び出されます。このシグナル・ハンドラーは、Java スレッドのために呼び出されたのか、または Java 以外のスレッドのために呼び出されたのかを判別します。
シグナルが Java スレッドのためのものである場合、JVM がシグナル処理の制御を行います。このシグナル用の アプリケーション・ハンドラーがインストール済みで、 -Xnosigchain コマンド行オプションを指定しなかった場合、 JVM の処理終了後に、このシグナル用のアプリケーション・ハンドラーが呼び出されます。
シグナルが Java 以外のスレッドのためのものであり、インストール済みのアプリケーションに、以前に JVM がそのシグナル用の独自のハンドラーをインストールしている場合、 制御はそのハンドラーに与えられます。そうでないと、シグナルが JVM または Java アプリケーションによって 要求されても、シグナルは無視されるか、または、デフォルトのアクションがとられます。
この規則の例外として、Windows では、外部的に生成されたシグナル (例えば、CTRL-BREAK を 入力した場合など) に対して、シグナル・ハンドラーを実行するために新しいスレッドが作成されます。 この場合、 JVM シグナル・ハンドラーがその処理を実行します。このシグナル用アプリケーション・ハンドラーが インストールされていて、-Xnosigchain コマンド行オプションを指定しなかった場合には、 このシグナル用のアプリケーション・ハンドラーが呼び出されます。
例外およびエラーのシグナルの場合、JVM は以下のいずれかを行います。
割り込みシグナルの場合にも JVM は制御されたシャットダウン・シーケンスに入りますが、この場合は、以下を行う正常終了として扱われます。
このシャットダウンは、Java メソッド System.exit() を呼び出すことによって開始されるシャットダウンと同一です。
JVM が使用するその他のシグナルは内部制御の目的のものであり、終了の原因となることはありません。関係のある 唯一の制御シグナルは SIGBREAK であり、これにより Javadump が生成されます。
下記の表 1 は、JVM が使用するシグナルを示したものです。 以下に、タイプまたは使用法ごとに表にグループ化したシグナルを示します
| シグナル名 | シグナル・タイプ | 説明 | -Xrs による使用不可 |
|---|---|---|---|
| SIGINT | 割り込み | 対話式アテンション (CTRL-C)。 JVM は正常に終了します。 | あり |
| SIGTERM | 割り込み | 終了要求。JVM は正常に終了します。 | あり |
| SIGBREAK | 制御 | 端末からのブレーク・シグナル。JVM は、Javadump を取るためにこれを使用します。 | あり |
|IBM JVM は、構造化された例外処理および |SetConsoleCtrlHandler() API を使用します。 |これらは、-Xrs で使用不可になります。-Xnosigchain は Windows で無視されます。
-Xrs (シグナル使用の削減) オプションを使用して、 JVM がほとんどのシグナルを処理してしまうのを防止します。詳しくは、 http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html にある、Sun の Java アプリケーション・ランチャーのページを参照してください。
JVM スレッド上のシグナル 2 (SIGINT) および 15 (SIGTERM) により、 JVM はシャットダウンします。したがって、アプリケーション・シグナル・ハンドラーでは、JVM を必要としなくなった場合を除き、 リカバリーを試みるべきではありません。
Runtime Environment にはシグナル・チェーニングが含まれています。シグナル・チェーニングにより、JVM は、独自のシグナル・ハンドラーをインストールするネイティブ・コードとの、より効率的な相互操作が可能となります。
シグナル・チェーニングにより、アプリケーションでは、msvcrt.dll の前に共用ライブラリー jsig.dll にリンクしてロードすることが可能になります。jsig.dll ライブラリーにより、signal() の呼び出しが確実にインターセプトされ、それらのハンドラーが JVM のシグナル・ハンドラーを置き換えることがなくなります。代わりに、これらの呼び出しは、新しいシグナル・ハンドラーを保管するか、または JVM がインストールしたハンドラーの後にそれらを「チェーニング」します。後で、これらのシグナルのいずれかが生じ、JVM をターゲットとしたものではないことが分かった場合、プリインストールされたハンドラーが起動します。
jsig.dll を使用するには、それを JVM を作成または組み込むアプリケーションとリンクします。
IBM SDK には、JAXP 1.3 仕様に準拠した XSLT4J プロセッサーと XML4J パーサーが含まれます。 これらのツールでは、XML 処理の実装とは関係なく、 XML 文書を解析および変換することができます。 「ファクトリー・ファインダー」を使用して SAXParserFactory、 DocumentBuilderFactory、および TransformerFactory の実装を見つけることによって、 アプリケーションは、コード変更の必要なく、異なる実装の間でスワップすることができます。
|IBM SDK に組み込まれている XML テクノロジーは、Apache Xerces Java および Apache Xalan Java と類似しています。 |詳しくは、http://xml.apache.org/xerces2-j/ |および http://xml.apache.org/xalan-j/ を参照してください。
XSLT4J プロセッサーでは、元の XSLT Interpretive プロセッサーまたは新しい XSLT Compiling プロセッサーを選択できます。 Interpretive プロセッサーは、ツールおよびデバッグ環境用に設計されたもので、 XSLT Compiling プロセッサーでサポートされない XSLT 拡張機能をサポートします。 XSLT Compiling プロセッサーは、ハイパフォーマンスのランタイム環境用に設計されたもので、 XSL スタイル・シートから変換エンジンであるトランスレット を生成します。 この方法により、ランタイム・アプリケーションから XML データへのスタイル・シート命令の解釈が分離されます。
XSLT Interpretive プロセッサーがデフォルト・プロセッサーです。 XSLT Compiling プロセッサーを選択するには、以下が可能です。
jaxp.properties ファイルのプロパティーを実装するには、jaxp.properties.sample を C:¥Program Files¥IBM¥Java50¥ の jaxp.properties にコピーします。 このファイルには、TransformerFactory、SAXParserFactory、および DocumentBuilderFactory について、使用する実装を判別するための手順に関する全詳細も含まれます。
XSLT Compiling プロセッサーでの StreamSource オブジェクトの変換時にパフォーマンスを向上させるには、 サービス org.apache.xalan.xsltc.dom.XSLTCDTMManager のプロバイダーとして com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager クラスを指定します。 サービス・プロバイダーを判別するには、org.apache.xalan.xsltc.dom.XSLTCDTMManager が見つかるまで、 各ステップを試行してください。
javax.xml.transform.TransformerFactory オブジェクトが作成されると、 XSLT Compiling プロセッサーは、org.apache.xalan.xsltc.dom.XSLTCDTMManager サービスのサービス・プロバイダーを検出します。 その TransformerFactory オブジェクトを使用して作成された javax.xml.transform.Transformer または javax.xml.transform.sax.TransformerHandler オブジェクトはすべて、同じサービス・プロバイダーを使用します。 上記のいずれかの設定を変更して、新しい TransformerFactory オブジェクトを作成することによってのみ、 サービス・プロバイダーを変更できます。
旧バージョンの Tomcat を使用している場合、次の制限が適用されます。
旧バージョン の Xerces (2.0 より前) または Xalan (2.3 より前) を endorsed ディレクトリーに入れて使用している場合、アプリケーションを起動したときにヌル・ポインター例外が起きる可能性があります。 この例外は、これらの古いバージョンが 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
以下の節では、SDK for Windows を使用した Java アプリケーションの開発について説明します。 使用可能なツールの詳細については、『SDK ツール』を参照してください。
Java プログラムをデバッグするには、Java Debugger (JDB) アプリケーション、あるいは SDK for Windows で提供される Java Platform Debugger Architecture (JPDA) を 使用して通信する他のデバッガーを使用できます。
Java Debugger (JDB) は、SDK for Windows に組み込まれています。このデバッガーは、 jdb コマンドで呼び出されると、JPDA を使用して JVM に接続します。 Java アプリケーションをデバッグするには、以下のようにします。
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> MyApp <MyApp args>
jdb -attach <port number>
デバッガーが JVM に接続したら、一連のコマンドを実行して Java アプリケーションを
検査し制御することができます。例えば、run と入力して Java アプリケーションを
実行させることができます。JDB オプションについて詳しく調べるには、次のように入力します。
jdb -help
JDB コマンドについて詳しく調べるには、次のようにします。
また、JDB を使用して、リモート・マシンで実行中の Java アプリケーションもデバッグできます。 JPDA は、TCP/IP ソケットを使用してリモート JVM に接続します。
jdb -attach <machine name または ip address>:<port number>
dt_socket トランスポートを使用してデバッグ・セッションを起動するとき、 指定のポートが空いていて使用できることを確認してください。
|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");
ネイティブ・プログラムが JNI_CreateJavaVM() API 呼び出しで指定できる有効な JNI バージョン番号は、以下のとおりです。
このバージョン番号で決まるのは、使用する JNI ネイティブ・インターフェースのレベルのみです。 作成される JVM の実際のレベルは、J2SE ライブラリーによって指定されます (つまり、v5.0)。 JNI インターフェース API は、JVM によって実装される言語仕様や、 クラス・ライブラリー API、その他の範囲の JVM 動作に影響しません。 詳しくは、http://java.sun.com/j2se/1.5.0/docs/guide/jni を参照してください。
32 ビット用に作成されたものと 64 ビット用に作成されたものの 2 つの JNI ライブラリーがアプリケーションで必要な場合、 com.ibm.vm.bitmode システム・プロパティーを使用して、 32 ビットまたは 64 ビット JVM のどちらで実行しているかを判別し、適切なライブラリーを選択します。
アプレット・ビューアーを使用すれば、Web ページ (HTML ファイル) 内から APPLET タグを使った 参照で呼び出される 1 つ以上のアプレットを実行できます。 アプレット・ビューアーは、HTML ファイルで APPLET タグを見つけると、タグで指定されているとおりに 別のウィンドウでそのアプレットを実行します。
アプレット・ビューアーは、アプレットを表示するためのものなので、HTML タグを数多く含む Web ページ全体は表示できません。 Web ページ上で APPLET タグのみを解析し、他の HTML タグは解析しません。
アプレットをアプレット・ビューアーで実行するには、コマンド・プロンプトで次のように入力します。
appletviewer name
ここで、name には、以下のいずれかを指定します。
例えば、アプレットの呼び出し元の HTML ファイルでアプレット・ビューアーを起動するには、 コマンド・プロンプトで次のように 入力します。
appletviewer <demo>¥GraphLayout¥example1.html
ここで、<demo> は、デモ・パッケージを unzip した先の絶対パスに置き換えます。
例えば、http://java.sun.com/applets/NervousText/example1.html が、アプレットを呼び出している Web ページの URL であるとします。この Web ページで アプレット・ビューアーを呼び出すには、シェル・プロンプトで次のように入力します。
appletviewer http://java.sun.com/applets/NervousText/example1.html
アプレット・ビューアーは、<META> タグの charset オプションは認識しません。 アプレット・ビューアーがロードするファイルが、システム・デフォルトとしてエンコードされていないと、 I/O 例外が発生する可能性があります。この例外を避けるには、アプレット・ビューアーを実行するときに、 -encoding オプションを使用します。 例えば、次のようにします。
appletviewer -encoding JISAutoDetect sample.html
アプレットをデバッグするには、アプレット・ビューアーの -debug オプションを使用します。アプレットをデバッグするときは、そのアプレットの呼び出し元の HTML ファイルが入っている ディレクトリーからアプレット・ビューアーを呼び出すことをお勧めします。 例えば、次のようにします。
cd <demo>¥TicTacToe appletviewer -debug example1.html
ここで、<demo> は、デモ・パッケージを unzip した先の 絶対パスに置き換えます。
アプレット・ビューアーを使用してアプレットをデバッグする方法についてのドキュメンテーションは、 Sun の Web サイト http://java.sun.com で参照できます。
| | |大規模ページをサポートするシステムで大規模ページ・サポートを使用可能にするには、 |-Xlp オプションを指定して Java を始動します。
|大規模ページは、多くのメモリーを割り振って頻繁にそのメモリーにアクセスする |アプリケーションのパフォーマンスを向上させるために使用するものです。 |大規模ページによるパフォーマンスの向上は、 |主に Translation Lookaside Buffer (TLB) のミスの数を減らすことによって実現します。 |TLB は、より大きな仮想メモリー範囲をマップし、それにより、この向上をもたらします。
|JVM が大規模ページを使用するためには、システムで、十分な数の連続した大規模ページが使用可能でなければなりません。 |十分なページが使用可能であっても、大規模ページを割り振れない場合、 |大規模ページが連続していない可能性があります。
|大規模ページの割り振りは、 |JVM ユーザーのローカル管理ポリシーが「Lock pages in memory」を許可するように構成されている場合にのみ、正常終了します。
Java 2 Platform, Standard Edition (J2SE) は、 J2SE (V1.5) の CORBA サポート公式仕様に定義されている仕様は最小限サポートしています。場合によっては、IBM J2SE ORB で、より新しいバージョンの仕様をサポートしている場合もあります。
この SDK は、OMG 資料「formal/99-10-07」の第 13 章 および 15 章の CORBA 2.3.1 仕様で定義されているように、すべてのバージョンの GIOP を サポートしています。この OMG 資料は、以下のサイトから入手できます。
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 を指定します。 しかし、このメソッドは Version 5.0 の 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 サービス技術員から要求される場合もあります。 トレースは、3 つのシステム・プロパティーで制御されます。
例えば、イベントとフォーマット済み GIOP メッセージをトレースするには、以下のように入力します。
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true myapp
パフォーマンスの低下につながるので、通常の業務ではトレースをオンにしないようにしてください。 トレースをオフに切り替えても、FFDC (First Failure Data Capture) は作動していて、重大なエラーだけは報告されます。 デバッグの出力ファイルが生成されたら、それを確認して問題について調べてください。例えば、 サーバーが ORB.shutdown() を実行せずに停止した可能性があります。
トレース出力の内容およびフォーマットは、バージョンによって異なります。
以下のプロパティーで、ORB の調整をすることができます。
例えば、フラグメント・サイズを 4096 バイトに設定するには以下のようにします。
java -Dcom.ibm.CORBA.FragmentSize=4096 myapp
デフォルトのフラグメント・サイズは、1024 バイトです。フラグメント・サイズを 0 に設定して フラグメント化をオフにすることができます。
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp
デフォルトで、ORB は、無制限に応答を待ちます。接続の不必要な終了を避けるため、 タイムアウトに低すぎる値を設定しないでください。
例えば、ORB がポート 1050 を使用するように設定する場合は以下のようにします。
java -Dcom.ibm.CORBA.ListenerPort=1050 myapp
このプロパティーを設定すると、ORB は、初期化後すぐに listen を開始します。 それ以外の場合は、要求されたときにのみ listen を開始します。
Java 2 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 実装クラスは以下のとおりです。
これらは、デフォルト値です。これらのプロパティーを設定しないか、または、 実装クラスを直接参照することをお勧めします。移植性を保つためには、実装ではなく、 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 では、接続プール内のスレッド数を制限するために使用できる設定はありません。
詳しくは、Sun の Java のサイト http://java.sun.com を参照してください。
IBM SDK には、拡張双方向言語サポートが含まれています。詳しくは、 http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html を参照してください。 双方向言語パッケージの Javadoc は、SDK でファイル docs/apidoc.zip に提供されます。
Java 5.0 以降、Sun により IBM BigDecimal クラスが java.math.BigDecimal として採用されました。 |IBM は com.ibm.math.BigDecimal の保守を止め、これは推奨されないものとして位置づけています。 |既存の Java コードをマイグレーションして java.math.BigDecimal を使用することをお勧めします。
|新しい java.math.BigDecimal は、以前の java.math.BigDecimal と com.ibm.math.BigDecimal |の両方と同じメソッドを使用しています。 |java.math.BigDecimal を使用している既存のコードは、そのまま正常に動作します。
|既存の Java コードを java.math.BigDecimal クラスを使用するようにマイグレーションするには、 |ご使用の java ファイルの先頭にある import ステートメントを、 |import com.ibm.math.*; から import java.math,*; に変更してください。
IBM SDK および Runtime Environment は 、2002 年 1 月 1 日以降、欧州通貨共同体 (EMU) の国々のデフォルトの通貨 としてユーロを設定しています。
各国の以前の通貨を使用する場合は、Java コマンド行で -Duser.variant=PREEURO を指定してください。
英国、デンマーク、あるいはスウェーデンのロケールを使用している場合で、ユーロを使用するには、 Java コマンド行で -Duser.variant=EURO を指定してください。
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 Version 5.0 Runtime Environment の入ったシステムに対応しています。
Java Communications API を使用すると、以下のことができます。
Java Communications API をインストールする前に SDK または Runtime Environment がインストール済みであることを 確認してください。
Java Communications API を zip ファイルからインストールするには以下のようにします。
Runtime Environment をインストールしたときに、デフォルト・ディレクトリーを受け入れている場合は、 comm.jar ファイルは、C:¥Program Files¥IBM¥Java50¥jre¥lib¥ext に入ります。
Java Communications API ファイルを別のディレクトリーに unzip すると、上記のファイルは同じディレクトリー構造で 配置されますが、C:¥Program Files¥IBM¥Java50¥ は、ファイルを unzip したディレクトリーと置き換えられます。
Java Communications API をインストール後、以下のことをしてください。
Java Communications API を使用して印刷をするときは、プリンターで 「用紙送り」または「継続」または、類似したボタンを押す必要があります。
Java Communications API をアンインストールするには、Runtime Environment をインストールした ディレクトリーから以下のファイルを削除します。
Runtime Environment は、デフォルトで C:¥Program Files¥IBM¥Java50¥ ディレクトリーにインストールされます。
API ドキュメンテーションと Java Communications API のサンプルは、次の Sun Web サイト http://java.sun.com で参照できます。
Java Plug-in は Web ブラウザー・プラグインです。 Java Plug-in を使用すると、 アプレットや Bean を Web ブラウザーで実行するために、 Web ブラウザーのデフォルト JVM を迂回して、代わりに、選択した Runtime Environment を使用することができます。
アプレットがロードを完了できるようにして、ブラウザーが「ハング」しないようにしてください。 例えば、「戻る」ボタンを使用してから、 アプレットのロード中に「進む」ボタンを使用すると、HTML ページがロードできない可能性があります。
Java Plug-in に関しては、Sun の http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/ に記述があります。
|
| |オペレーティング・システム | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| |Windows 2000 | |5.5 SP2、6.0 | |4.78、6.2.2、7.2 | |1.4.x、1.5.x、1.6.x、1.7.x、Firefox 1.0.x |
| |Windows XP | |6.0 | |4.78、6.2.2、7.2 | |1.4.x、1.5.x、1.6.x、1.7.x、Firefox 1.0.x |
| |Windows Server 2003 | |6.0 | |4.78、6.2.2、7.2 | |1.4.x、1.5.x、1.6.x、1.7.x、Firefox 1.0.x |
Windows 2000 のデフォルト・ブラウザーである Internet Explorer 5.01 はサポートされません。
特定のブラウザーによる制約のために、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 ファイルを解析するように指示するものです。すべてのパラメーターが正しく Java Plug-in に渡されます。 しかし、一部の古いバージョンのブラウザーでは、このタグが正しく認識されないことがあります。その場合には、ブラウザーにこのタグを無視するように強制できますが、エンコードを手動で変更しなければならないこともあります。
次のようにして、HTML ファイルの解析に使用するエンコード方式を指定することができます。
Java アプリケーションを配置するために Java Web Start を使用できます。Web Start によって ユーザーは、Web から直接アプリケーションを起動し、管理することができます。Java Web Start を使用すれば、Web で簡単にアプリケーションを開始することができます。その際、 確実に最新バージョンを稼働することができ、インストールやアップグレードの手間も省けます。 Java Web Start により、ソフトウェアのダウンロードやインストールの必要もなくなり、時間のかかる インストール・オプションの設定も回避できます。
|http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources に文書化されている java-vm-args のほかに、Web Start は、ガーベッジ・コレクション・ポリシーを設定する |-Xgcpolicy をサポートします。
Web Start をサポートするブラウザーについて詳しくは、『サポートされるブラウザー』を参照してください。
Web Start についての詳細は、http://java.sun.com/products/javawebstart および http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html を参照してください。アプリケーションの配置についての詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html を参照してください。
Web Start は、以下の 3 つの方法で起動できます。
アプリケーションは、ダウンロードされると、Java アプリケーション・キャッシュに保管されます。 そのアプリケーションが再アクセスされたときに、Java Web Start は、 アプリケーションの最新のバージョンがあればダウンロードし、 なければキャッシュ内のものを使用します。
.jnlp ファイルでエラーが発生すると (無効なタグ名など)、Web Start はエラー・メッセージを表示せずに失敗します。
Java アプレットと異なり、Java アプリケーションは、インストールおよびランタイム・サービスについて Web ブラウザーに依存することができません。 Java アプリケーションを出荷する場合、 ソフトウェア・パッケージは、多くの場合、以下のパーツから構成されます。
アプリケーションを実行するには、ユーザーに Runtime Environment for Windows が必要です。 SDK for Windows ソフトウェアには Runtime Environment が含まれます。ただし、 ユーザーが SDK for Windows ソフトウェアをインストール済みであることを前提にすることはできません。
SDK for Windows ソフトウェアのライセンスでは、 SDK のファイルをアプリケーションとともに再配布することが許可されません。 ライセンス交付を受けた SDK for Windows がターゲット・マシンにインストールされていることを確認してください。
| | |IBM Virtual Machine (VM) では、共用メモリーのキャッシュに保管することによって、 |VM 間でブートストラップおよびアプリケーション・クラスを共用することができます。 |複数の VM がキャッシュを共用する場合、クラス共用で全体の仮想メモリー使用量が削減されます。 |また、クラス共用によって、キャッシュ作成後の VM の起動時間も短縮されます。 |共用クラス・キャッシュは、どのアクティブ VM からも独立したもので、 |キャッシュを開始した VM の存続期間を超えて存続します。
| |IBM SDK では、可能な限り多くのクラスを共用でき、 |一方、ユーザーはそれを意識しません。
| |共用クラス・キャッシュには、読み取り専用の静的クラス・データと、クラスを記述するメタデータが含まれます。 |任意の VM が、キャッシュの読み取りや更新を行えます。共用している VM は、同じリリースでなければなりません。 |実行時バイトコード変更を使用する場合は、注意が必要です。 |(『実行時バイトコード変更』を参照)
| |共用クラス・キャッシュは任意の VM の存続期間を超えて存続するため、 |ファイル・システムで JAR やクラスに行われた可能性がある変更を反映するよう、 |キャッシュは動的に更新されます。動的更新により、キャッシュを使用するアプリケーションでキャッシュを意識する必要がなくなります。
| |VM の始動時に -Xshareclasses オプションを使用してクラス共用を使用可能にすると、 |VM を既存のキャッシュに接続させるか、それが存在しない場合には作成します。 |VM によってロードされるすべてのブートストラップおよびアプリケーション・クラスが、 |デフォルトで共用されます。カスタム・クラス・ローダーは、アプリケーション・クラス・ローダーを継承している場合、 |自動的に共用します。それ以外の場合は、VM で提供される Java ヘルパー API |を使用してそのキャッシュにアクセスする必要があります。(『カスタム・クラス・ローダーの共用クラスへの適応』を参照)
| |共用クラス・キャッシュへのアクセスは、オペレーティング・システムの許可と |Java セキュリティーの許可によって制限されます。 |クラスの共用を登録したクラス・ローダーのみが、共用クラス・キャッシュにクラスを追加できます。 |Java SecurityManager がインストールされている場合、 |デフォルト・ブートストラップ、アプリケーション、および拡張クラス・ローダーを除いて、 |クラス・ローダーには、クラス SharedClassPermission を java.policy ファイルに追加することによって、 |クラス共用の許可を付与する必要があります。(『SharedClassPermission の使用』を参照) |RuntimePermission 「createClassLoader」は、新しいクラス・ローダーの作成を制限し、 |したがって、キャッシュへのアクセスも制限します。
| |1 つのシステムに複数のキャッシュが存在することが可能で、それらは、 |-Xshareclasses コマンドのサブオプションとして名前で指定されます。 |1 つの VM は、常に 1 つのキャッシュにのみ接続できます。 |キャッシュ・サイズは、始動時に -Xscmx<n>[k|m|g] で指定し、その後、 |キャッシュの存続期間中このサイズは変わりません。 |キャッシュは、-Xshareclasses コマンドのサブオプションを使用して明示的に破棄されるか、 |システムがリブートされるまで存在します。
| |キャッシュ・ユーティリティーはすべて、-Xshareclasses コマンドのサブオプションです。 |-Xshareclasses:help で、使用可能なサブオプションのリストが表示されます。
| |クラス共用は、-Xshareclasses および -Xscmx コマンド行オプションにより使用可能にし、構成します。
|クラス共用を使用可能にするには、アプリケーション・コマンド行に |-Xshareclasses[:name=<name>] を追加します。 |VM は、指定された名前の既存キャッシュに接続するか、その名前の新しいキャッシュを作成します。 |新しいキャッシュが作成された場合、キャッシュが満杯になるまで、 |ロードされるすべてのブートストラップおよびアプリケーション・クラスがそれに取り込まれます。 |2 つ以上の VM が同時に始動された場合、 |それらすべてが同時にキャッシュにデータの取り込みをします。
|キャッシュが作成されたことを確認するには、java -Xshareclasses:listAllCaches を実行します。 |共用されるクラス数とクラス・データ量を確認するには、java -Xshareclasses:[name=<name>],printStats を実行します。 |(このユーティリティーは、アプリケーション VM の終了後か、別のコマンド・ウィンドウで実行できます)
|キャッシュからロードされる、またはキャッシュに保管されるクラスを確認するには、 |アプリケーション・コマンド行に -Xshareclasses:[name=<name>],verbose を追加します。
|作成されたキャッシュを削除するには、java -Xshareclasses:[name=<name>],delete を実行します。 |キャッシュに多くの stale クラスが含まれるか、キャッシュが満杯で、より大きいキャッシュを作成したい場合にのみ、 |キャッシュを削除する必要があります。
|キャッシュ・サイズは、個別のアプリケーションに応じて調整することが推奨されます。 |これは、デフォルトが最適サイズである可能性が低いためです。 |最適なキャッシュ・サイズを判別する最も良い方法は、 |大容量のキャッシュを指定 (-Xscmx を使用) してアプリケーションを実行し、 |どのぐらいのクラス・データが保管されたかを printStats で判別することです。 |printStats で示された値に、予備のために少量を加算します。 |クラスは、VM 存続期間中のどの時点でもロードされる可能性があるため、 |この分析はアプリケーションの終了後に行うのが最適です。 |ただし、キャッシュが満杯であることが、それに接続された VM のパフォーマンスや機能に悪影響を与えることはありません。 |そのため、キャッシュ・サイズを必要より小さくすることは、非常に合理的です。
|キャッシュが満杯になると、そのキャッシュを使用しているすべての VM のコマンド行に、メッセージが出力され、 |それ以降のクラスは、その VM 自身のプロセス・メモリーにロードされます。 |満杯のキャッシュ内のクラスは、依然として共用可能ですが、 |満杯のキャッシュは読み取り専用で、新しいクラスで更新することはできません。
| |クラス共用は、類似したコードを実行する複数の VM を使用するシステムで特に有用です。 |そうしたシステムは、仮想メモリー使用量を削減することができます。 |また、VM の始動とシャットダウンを頻繁に行うシステムでも有用で、起動時間を改善することができます。
|新しいキャッシュの作成とデータ取り込みのオーバーヘッドは、わずかです。 |1 つの VM に対する VM 起動時間は通常、ロードされるクラスの数に応じて、クラス共用を使用していないシステムと比べて 0 から 5 % 抑えられます。 |データ取り込み済みのキャッシュを使用すると、VM 起動時間は通常、 |オペレーティング・システムとロードされるクラスの数に応じて、クラス共用を使用していないシステムと比べて 10 % から 40 % 向上します。 |複数の VM が並行して稼働する場合、全体の起動時間がさらに大きく向上します。
|クラス共用によりアプリケーションを実行する場合、オペレーティング・システム・ツールを使用して、 |仮想メモリー使用量の削減を確認することができます。
| |理論上の最大キャッシュ・サイズは 2 GB です。キャッシュは次の要因によって制限されます。
| |バイトコードの変更が可能な JVMTI エージェントを使用する VM は、 |modified=<modified_context> サブオプションがコマンド行で使用されていない限り、クラスを共用できません (前述)。 |modified context (変更コンテキスト) は、実行される変更のタイプを記述する、ユーザー指定の記述子です。 |指定された変更コンテキストを使用するすべての VM は、 |キャッシュに保管された変更クラスが、別の VM によってロードされたときに、期待どおりに変更されるように、 |各クラスに対して予測可能で反復可能な方法でバイトコードを変更する必要があります。 |変更が予測可能でなければならない理由は、共用クラス・キャッシュからロードされたクラスを |エージェントがもう一度再変更することができないためです。 |変更されたバイトコードと変更されていないバイトコードを同じキャッシュに保管することができます。 |このトピックについて詳しくは、「Diagnostics Guide (英語)」を参照してください。
| |32 ビット・アプリケーションと |64 ビット・アプリケーションの両方を実行できるオペレーティング・システムの場合、 |32 ビット VM と 64 ビット VM の間でクラス共用は許されません。 |listAllCaches サブオプションでは、使用される VM のアドレス・モードに応じて、 |32 ビットまたは 64 ビットのキャッシュがリストされます。
|共用クラス・キャッシュは、 |システムに存在するキャッシュに関する識別情報を保管するためのディスク・スペースを必要とします。 |この情報は、ユーザー・プロファイル・ディレクトリーに置かれます。 |識別情報ディレクトリーが削除された場合、 |VM はシステム上の共用クラスを識別できず、キャッシュを再作成する必要があります。
|共用クラス・キャッシュにアクセスするための許可は、 |オペレーティング・システムによって執行されます。キャッシュ名が指定されない場合、 |同じシステム上の複数のユーザーがデフォルトで独自のキャッシュを作成するように、 |デフォルト名にユーザー名が付加されます。
| |クラス共用と併せて SecurityManager が使用され、 |実行アプリケーションがそれ自身のクラス・ローダーを使用する場合、 |クラスを共用するにはその前に、これらのクラス・ローダーにクラス共用の許可が付与されていなければなりません。 |クラス・ローダーのクラス名 (ワイルドカードを使用可) と、付与されるアクセス権を決める "read"、"write"、または "read,write" |のいずれかを指定して、java.policy ファイルに SharedClassPermission を追加します。 |例えば、次のようにします。 |
|permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
クラス・ローダーに適切な SharedClassPermission がなく、それがクラスを共用しようとすると、 |AccessControlException がスローされます。 |デフォルトのブートストラップ、アプリケーション、または拡張クラス・ローダーの許可は、 |変更または削減できません。
| |ほとんどの Java アプリケーションは、VM 独自のクラス・ローダーを使用するか、 |java/net/URLClassLoader を継承するカスタム・クラス・ローダーを持ちます。 |これらのクラス・ローダーを使用するアプリケーションは、 |ブートストラップおよびアプリケーション・クラスを自動的に共用することができます。 |java/net/URLClassLoader を継承しないカスタム・クラス・ローダーには、 |クラス共用を利用するための変更が必要になります。 |SecurityManager が使用される場合、すべてのカスタム・クラス・ローダーに、クラス共用の許可が付与される必要があります。『SharedClassPermission の使用』を参照してください。 |IBM は、カスタム・クラス・ローダーのさまざまなタイプに応じたいくつかの Java インターフェースを提供しています。 |これにより、そのクラス・ローダーが、共用クラス・キャッシュでクラスを検出および保管することができます。 |これらのクラスは、com.ibm.oti.shared パッケージにあります。 |このパッケージの Javadoc は、SDK でファイル docs/apidoc.zip に提供されます。 |これらのインターフェースの使用方法について詳しくは、 |「Diagnostics Guide (英語)」を参照してください。
IBM Solutions Developer Program に準ずるプログラム・コードのサービスを受けられる場合、 通常の利用方法によって、または Web (http://www-1.ibm.com/partnerworld/) で IBM Solutions Developer Program にお問い合わせください。
サービス契約 (つまり、IBM の Personal Systems Support Line または各国における同等サービス) を購入している場合は、 そのサービス契約の条件によって、そのプログラムに関して受けられるサービス (該当がある場合) が決まります。
この SDK および Runtime Environment で提供されるこのユーザー・ガイドは、スクリーン・リーダーを使用して テストしてあります。 このユーザー・ガイドは、ホームページ・リーダーあるいは JAWS スクリーン・リーダーなどの スクリーン・リーダーを使用することができます。
ユーザー・ガイドのフォント・サイズを変更するには、ご使用のブラウザーで提供される機能を使用して ください。通常、「表示」メニュー・オプションにあります。
キーボード・ナビゲーションが必要なユーザーの場合、Swing アプリケーション用の便利なキー・ストロークの説明が http://www-128.ibm.com/developerworks/java/jdk/additional/ の「Swing Key Bindings」にあります。
|GUI に加えて、iKeyman ツールには、コマンド行ツールの |IKEYCMD があり、これには、iKeyman GUI と同じ機能があります。 |IKEYCMD では、鍵、証明書、および認証要求を管理することができます。 |IKEYCMD は、アプリケーションで証明書や鍵の管理タスクにカスタム・インターフェースを追加する必要が |ある場合に使用するプログラムおよびネイティブ・シェル・スクリプトから呼び出すことができます。 |IKEYCMD は、iKeyman で現在サポートするすべての型の |鍵データベース・ファイルを作成できます。 |また、IKEYCMD は、認証要求を作成したり、CA 署名証明書をインポートしたり、 |さらに自己署名証明書を管理したりすることもできます。
IKEYCMD コマンドを実行するには、以下のように入力してください。
java [-Dikeycmd.properties=<properties file>] com.ibm.gsk.ikeyman.ikeycmd <object> <action> [options]
ここで、
詳しくは、http://www.ibm.com/developerworks/java/jdk/security/index.html の「iKeyman User Guide (英語)」を参照してください。
カーソル・キーを使用して JComboBox コンポーネントのドロップダウン・リストを上下に探索する場合、実際に項目が選択されるまで コンボ・ボックスのボタンあるいは編集可能フィールドは変更されません。 これは、このリリースで望ましい動作で、キーボードによる探索動作とマウスによる探索動作の 一貫性が保たれるため、アクセス可能度や使用可能度が向上します。
IBM Java Web Start v5.0 では、前のリリースよりアクセス可能度と使用可能度において 種々の改善がなされて、例えば、スクリーン・リーダーのサポートが充実し、 キーボード・ナビゲーションも改善されています。
コマンド行のみで、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 32-bit SDK for Windows v5.0 における以下の制限に注意してください。
この例外が発生したら、システム・プロパティー java.nio.debug=pipe を設定して、どのポート番号がブロックされているかを確認してください。
本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。
http://www.ibm.com/jp/manuals/main/mail.html
なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは
http://www.ibm.com/jp/manuals/ の「ご注文について」をご覧ください。
(URL は、変更になる場合があります)
ただし、IBM にメッセージを送る際には、フィードバック・データ (質問、意見、提案事項など) を含め、メッセージに組み込む情報はすべて公表を承諾されたものとみなされること、IBM ではこれらの情報をいかなる義務も負うことなく、無制限にコピー、利用、開示し、かつ他に対して配布できることをご承知おきください。さらに、IBM では、これらの情報に含まれるすべての着想、概念、ノウハウ、または技術を、製品の開発、製造、および販売など、あらゆる目的に利用できるものとします。
本書は米国 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 は、IBM Corporation の商標です。
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Microsoft、Windows、および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
この製品は、一部分 FreeType Project の作業にも基づいています。Freetype の詳細については、http://www.freetype.org を参照してください。
この製品には、The Apache Software Foundation (http://www.apache.org/) によって開発されたソフトウェアが含まれています。