本書および本書で紹介する製品をご使用になる前に、特記事項に記載されている情報をお読みください。
本書は、複数のプラットフォーム上の IBM SDK and Runtime Environment for Linux に適用されます。
本書が適用されるプラットフォームは以下のとおりです。
これに加えて、新しい版で明記されていない限り、これらの製品の上記以降のすべてのリリースおよびモディフィケーションに適用されます。
(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) SDK and Runtime Environment for Linux(R) platforms, Java(TM) Technology Edition, Version 6 の概説と、 Sun の実装と対比した IBM の実装の相違点に関する具体的な情報が記載されています。
本書は、Sun の Web サイト (http://java.sun.com) の詳細な資料と一緒にお読みください。
SDK および Runtime Environment for Linux をテスト済みのディストリビューションのリストについては、http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html を参照してください。
(Intel(R) 32 ビット・プラットフォームのみ) 以下の仮想化環境がサポートされています。
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 Linux が 含まれています。SDK をインストールしている場合には、Runtime Environment が組み込まれています。
Runtime Environment には、Java 仮想マシンと、デバッグ不可能な .so ファイルと、クラス・ファイルなどのサポート・ファイルが含まれています。Runtime Environment には、SDK にあるクラスのサブセットのみが含まれているため、実行時に Javaプログラムをサポートすることはできますが、Java プログラムのコンパイルはできません。Runtime Environment for Linux には、appletviewer または Java コンパイラー (javac) などの開発ツールや、開発システム専用のクラスは一切含まれていません。
さらに、IA32、PPC32/PPC64、および AMD64/EM64T プラットフォームの場合は、Java Communications のアプリケーション・プログラミング・インターフェース (API) パッケージ が Runtime Environment for Linux と一緒に使用するために提供されています。 これについては、Java Communications API (JavaComm) の使用を参照してください。
license_xx.html ファイルには、Runtime Environment for Linux ソフトウェアのご使用条件が含まれています (xx は言語の省略語です)。ご使用条件を 表示あるいは印刷するには、Web ブラウザーでこのファイルをオープンしてください。
本書では、SDK のデフォルト・インストール・ディレクトリーに言及する場合、/opt/ibm/java-i386-60/ を使用します。 Linux IA 32 ビットを使用していない場合、デフォルト・インストール・ディレクトリーは異なります。
以下のリストに示すプラットフォームでは、それぞれデフォルトのインストール・ディレクトリーが異なります。このため、/opt/ibm/java-i386-60/ が出現した場合には、使用しているプラットフォームのディレクトリーに置き換えてください。
本書の例では、Korn シェル・コマンドを使用します。
以前のバージョンの SDK で稼働したアプレットまたはアプリケーションは、一般に、IBM SDK for Linux, v6 でも正しく動作します。 このリリースでコンパイルしたクラスについて、前のリリースでの動作は保証できません。
リリース間での互換性について詳しくは、以下の 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 Linux には、新しいバージョンの IBM Virtual Machine for Java と Just-In-Time (JIT) コンパイラーが含まれています。
以前の IBM Runtime Environment からマイグレーションする場合は、以下のことに注意してください。
System z31-bit SDK および 64-bit SDK と Runtime Environment は、System z9(TM) および zSeries(R)ハードウェア上で稼働します。
SDK および Runtime Environment は、以下のサーバーまたは同等のサーバー上で稼働します。
SDK には、いくつかの開発ツールと Java Runtime Environment (JRE) が含まれています。この節では、SDK ツールと Runtime Environment のコンテンツについて説明します。
全体が Java で書かれたアプリケーションでは、IBM SDK のディレクトリー構造 (あるいは、それらのディレクトリー内のファイル) に対する依存関係が皆無であるべきです。SDK のディレクトリー構造 (あるいは、それらのディレクトリー内のファイル) に対する依存関係があると、 アプリケーションの移植性の問題が生じる場合があります。
この SDK for Linux に組み込まれているドキュメンテーションは、ユーザー・ガイド、Javadoc、および付随するライセンス、著作権ファイル、javadoc、および demo ディレクトリーのみです。Sun の Web サイト (http://java.sun.com) にアクセスして Sun のソフトウェア・ドキュメンテーションを表示するか、あるいは、この Web サイトから Sun の ソフトウェア・ドキュメンテーション・パッケージをダウンロードすることができます。
標準的な Runtime Environment と一緒に使用できるクラスおよびツールのリストです。
標準 SDK に含まれているツールと参照情報のリストです。
ライセンス・ファイル /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>には、SDK for Linux ソフトウェアのご使用条件が含まれています (<locale> は使用するロケールの名前です。例えば en)。ご使用条件を 表示あるいは印刷するには、Web ブラウザーでこのファイルをオープンしてください。
IBM Java SDK and Runtime Environment は、RPM または .tgz ファイルからインストールできます。マシン上のすべてのユーザーに、この Java インストール済み環境へのアクセス権限を付与するのでない限り .tgz によるインストール方法を使用してください。 root アクセス権限を持っていない場合は .tgz ファイルを使用してください。
RPM ファイルを使用してインストールする場合は、Java ファイルは、/opt/ibm/java-i386-60/ にインストールされます。 本書の例は、Java が、このディレクトリーにインストールされていることを前提としています。
SDK を前のリリースからアップグレードする場合は、アップグレードを開始する前に、 すべての構成ファイルおよびセキュリティー・ポリシー・ファイルをバックアップしてください。
これらのファイルはアップグレード処理中に上書きされた可能性があるため、 アップグレードの後に、それらのリストアまたは再構成が必要な場合があります。 ファイルのフォーマットやオプションが変わった可能性があるため、 元のファイルをリストアする前に、新しいファイルの構文を確認してください。
SDK は共用ライブラリーに依存しますが、これらのライブラリーは、デフォルトでは Red Hat Enterprise Linux (RHEL) 用にインストールされません。
RHEL 4 では、これらのライブラリーを含む RPM は、次のとおりです。
RHEL 4 のインストール中にこれらのライブラリーを組み込むには、次のようにします。
SDK は共用ライブラリーに依存しますが、これらのライブラリーは、デフォルトでは Red Hat Enterprise Linux (RHEL) 用にインストールされません。
RHEL 5 では、これらのライブラリーを含む RPM は、次のとおりです。
RHEL 5 のインストール中にこれらのライブラリーを組み込むには、次のようにします。
SELinux が使用可能になっている Red Hat Enterprise Linux Version 5 上で IBM SDK for Java を実行するには、Java をデフォルト・ディレクトリーにインストールするか、コマンドを入力する必要があります。
Java がデフォルト・ディレクトリーにインストールされていない場合は、次のコマンドを入力します。
chcon -R -t texrel_shlib_t <path_of_sdk>
ここで、<path_of_sdk> は、Java のインストール先のパスです。
SELinux について手詳しくは、Red Hat 資料の『Introduction to SELinux』を参照してください。
SDK を実行するには、SDK (32 ビットまたは 64 ビット) で必要なすべてのライブラリーの正しいバージョンをインストールする必要があります。
RHEL4 では、64 ビット・バージョンのパッケージは、「Compatibility Arch Support」パッケージ・グループにあります。
RPM ツールを使用して、インストール済みのパッケージのバージョンを確認できます。これを行うには、RPM コマンドに --queryformat "%{NAME}.%{ARCH}¥n" オプションを追加します。例えば、次のようにします。
/home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++ libstdc++.x86_64 libstdc++.i386
RPM ファイルからインストールするための手順です。
rpm ツールを使用して JVM をアップグレードするには、旧バージョンをすべてアンインストールする必要があります。JVM の 2 つのバージョンを別々の場所にインストールするには、rpm --force オプションを使用してバージョンの競合を無視するか、JVM を .tgz ファイルからインストールします。
rpm -ivh ibm-java2-<arch>-sdk-6.0-0.0.<arch>.rpmまたは
rpm -ivh ibm-java2-<arch>-jre-6.0-0.0.<arch>.rpm
ここで、<arch> は、アーキテクチャー (i386、x86_64、ppc、ppc64、s390、または s390x) を表します。
.tgz ファイルからインストールするための手順です。
tar -zxvf ibm-java2-sdk-60-linux-<arch>.tgzまたは
tar -zxvf ibm-java2-jre-60-linux-<arch>.tgz
ここで、<arch> はアーキテクチャー (i386、x86_64、ppc、ppc64、s390、または s390x) を表します。
chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib
IBM Java パッケージは、JPackage 互換フォーマットでも使用可能です。
SDK の管理を簡略化するために、SDK のさまざまなコンポーネントを別個の RPM として使用できるようになりました。これらのコンポーネントは、基本 Java Runtime Environment、Development Kit、Plug-in、JDBC、Demo、Sound、Source、および Fonts です。システム上の複数の Java RPM の管理を可能にする "jpackage-utils" RPM (http://jpackage.org からダウンロード可能) も、IBM SDK の前提条件です。JPackage 仕様について詳しくは、http://jpackage.org を参照してください。
Red Hat Advanced Server でのフォント・エンコードの不整合
PATH 環境変数を変更すると、ご使用のパスにある既存の Java ランチャーがすべてオーバーライドされます。
PATH 環境変数により、Linux は、どの現行ディレクトリーからでも javac、java、および javadoc などのプログラムおよびユーティリティーを見つけられるようになります。ご使用の PATH の現行値を表示するには、コマンド・プロンプトで次のように入力します。
echo $PATH
ご使用のパスに Java ランチャーを追加するには、次のようにします。
export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
パスを設定した後は、任意のディレクトリーからコマンド・プロンプトでツールの名前を入力することにより、ツールを実行できます。例えば、ファイル Myfile.Java をコンパイルするには、コマンド・プロンプトで、以下のように入力します。
javac Myfile.Java
クラスパスにより、SDK ツール (java、javac、および javadoc など) は Java クラス・ライブラリーがある場所がわかります。
以下に該当する場合のみ、クラスパスを明示的に設定する必要があります。
CLASSPATH 環境変数の現行値を表示するには、シェル・プロンプトで次のコマンドを入力します。
echo $CLASSPATH
別にインストール済みの他のバージョンも含めて、 異なるランタイム環境を使用する複数のアプリケーションを作成し実行する場合、CLASSPATH および PATH をアプリケーションごとに明示的に設定する必要があります。複数アプリケーションを 同時に実行し、異なるランタイム環境を使用する場合、それぞれのアプリケーションが固有のシェル・プロンプトで実行される必要があります。
SDK and Runtime Environment for Linux を除去するためのプロセスは、実行したインストールのタイプによって異なります。
手順については、『Red Hat Package Manager (RPM) パッケージのアンインストール』または『Tape Archive (TAR) 圧縮パッケージのアンインストール』を参照してください。
Red Hat Package Manager (RPM) パッケージをアンインストールするための手順です。
インストール可能 RPM パッケージをインストールしてある場合、SDK or Runtime Environment for Linux をアンインストールするには、次のようにします。
インストール済みのすべての IBM Java パッケージのリストが表示されます。例えば、次のようになります。
ibm-java2-<arch>-jre-6.0-0.0.<arch> ibm-java2-<arch>-sdk-6.0-0.0.<arch>
この出力は、次のような rpm -e コマンドを使用してアンインストールできるパッケージを示しています。
rpm -e ibm-java2-<arch>-jre-6.0-0.0.<arch> rpm -e ibm-java2-<arch>-sdk-6.0-0.0.<arch>
あるいは、kpackage や yast2 などのグラフィック・ツールを使用することもできます。
圧縮パッケージから抽出された IBM SDK for Linux, v6 を除去するためのステップのリストです。
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 20070329_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT enabled) J9VM - 20070326_12091_lHdSMR JIT - dev_20070326_1800 GC - 20070319_AA)ビルド日とバージョンが変更されます。
|
| また、以下のコマンドを入力すると、クラスパス、ブート・クラスパス、および拡張ディレクトリーにあるすべての利用可能な jar ファイルのバージョン情報を表示することもできます。
java -Xjarversion|
以下に類似した情報が表示されます。
|... |/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar VERSION: 1.0 build_20070125 |/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar |/opt/ibm/java-i386-60/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
export 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 が戻す、エラーの詳細説明やその他のデバッグ情報は、英語で表示されます。
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 アプリケーションをデバッグするときの問題の切り分けに役立つ、一時的な手段です。
export JAVA_COMPILER=NONE
java -Djava.compiler=NONE <class>
java -Xint <class>
デフォルトでは JIT は使用可能になっています。JIT は、以下のいくつかの異なる方法で明示的に使用可能にできます。どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。
export JAVA_COMPILER=jitcJAVA_COMPILER 環境変数が空ストリングの場合、JIT は使用不可のままになります。環境変数を使用不可に設定するには、シェル・プロンプトで以下を入力します。
unset 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 を指定してください。
Linux フォールバック・フォント構成ファイル (fontconfig.RedHat.bfc および fontconfig.SuSE.bfc) は、新しいエンタープライズ Linux ディストリビューションに適したフォント設定を提供するためにインストールされています。
これらのファイルは、便宜的に提供されているに過ぎません。これらのファイルが存在するからといって、新しい Linux ディストリビューションが、IBM SDK and Runtime Environment for Linux platforms, Java Technology Edition, Version 6 のサポート対象プラットフォームであることを意味するものではありません。
| | |バージョン 6 では、インドおよびタイ語の入力方式はデフォルトでは使用できません。インドおよびタイ語の入力方式を使用するには、入力方式の jar ファイルを Java 拡張パスに手動で組み込む必要があります。
バージョン 5.0 では、入力方式の jar ファイルは jre/lib/ext ディレクトリーに含まれており、JVM によって自動的にロードされていました。バージョン 6 では、入力方式の jar ファイルは jre/lib/im ディレクトリーに含まれており、インドおよびタイ語の入力方式を使用可能にするには、これを Java 拡張パスに手動で追加する必要があります。これは、以下のいずれかの方法を使用して実現できます。
|java -Djava.ext.dirs=/opt/ibm/java-i386-60/jre/lib/ext:/opt/ibm/java-i386-60/jre/lib/im <class>
|
SDK または Runtime Environment を別のディレクトリーにインストールした場合、SDK または Runtime Environment をインストールした |ディレクトリーで /opt/ibm/java-i386-60/ を置き換えてください。
SDK for Linux には、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 ファイルを正しく処理しないために起きます。
|
この状態を避けるために、以下の次善策のいずれかを使用してください。 | |
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
または
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
または
|export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
Java プログラムをデバッグするには、Java Debugger (JDB) アプリケーション、あるいは SDK for Linux で提供される Java Platform Debugger Architecture (JPDA) を 使用して通信する他のデバッガーを使用できます。
Java を使用した問題診断について詳しくは、「Diagnostics Guide (英語)」を参照してください。
Java Debugger (JDB) は、SDK for Linux に組み込まれています。このデバッガーは、 jdb コマンドで呼び出されると、JPDA を使用して JVM に接続します。
Java アプリケーションをデバッグするには、以下のようにします。
java -Xdebug -Xrunjdwp:transport=dt_socket,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_socket,server=y,address=<port> <class>JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。
jdb -attach <host>:<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 アプリケーションによって要求されても、シグナルは無視されるか、または、デフォルトのアクションがとられます。
例外およびエラーのシグナルの場合、JVM は以下のいずれかを行います。
割り込みシグナルの場合にも JVM は制御されたシャットダウン・シーケンスに入りますが、この場合は、以下を行う正常終了として扱われます。
このシャットダウンは、Java メソッド System.exit() を呼び出すことによって開始されるシャットダウンと同一です。
JVM が使用するその他のシグナルは内部制御の目的のものであり、終了の原因となることはありません。関係のある 唯一の制御シグナルは SIGQUIT であり、これにより Javadump が生成されます。
シグナルのタイプには、例外、エラー、割り込みおよび制御があります。
下記の表 7 は、JVM が使用するシグナルを示したものです。 以下に、タイプまたは使用法ごとに表にグループ化したシグナルを示します。
シグナル名 | シグナル・タイプ | 説明 | -Xrs による使用不可 |
---|---|---|---|
SIGBUS (7) | 例外 | メモリーに対する誤ったアクセス (データの調整ミス) | あり |
SIGSEGV (11) | 例外 | メモリーに対する誤ったアクセス (アクセス不能メモリーへの書き込み) | あり |
SIGILL (4) | 例外 | 正しくない命令 (不明なマシン・インストラクション呼び出しの試行) | なし |
SIGFPE (8) | 例外 | 浮動小数点例外 (ゼロ除算) | あり |
SIGABRT (6) | エラー | 異常終了。JVM が JVM 障害を検出すると、このシグナルを生じさせます。 | あり |
SIGINT (2) | 割り込み | 対話式アテンション (CTRL-C)。 JVM は正常に終了します。 | あり |
SIGTERM (15) | 割り込み | 終了要求。JVM は正常に終了します。 | あり |
SIGHUP (1) | 割り込み | ハングアップ。JVM は正常に終了します。 | あり |
SIGQUIT (3) | 制御 | 端末用の終了シグナル。デフォルトでは、Javadump が起動されます。 | あり |
SIGTRAP (5) | 制御 | JIT が使用します。 | あり |
__SIGRTMAX - 2 | 制御 | SDK が使用します。 | なし |
SIGCHLD (17) | 制御 | 内部制御のために SDK が使用します。 | なし |
-Xrs (シグナル使用の削減) オプションを使用して、 JVM がほとんどのシグナルを処理してしまうのを防止します。詳しくは、 Sun の 『Java application launcher』ページを参照してください。
JVM スレッド上のシグナル 1 (SIGHUP)、2 (SIGINT)、4 (SIGILL)、7 (SIGBUS)、8 (SIGFPE)、11 (SIGSEGV)、および 15 (SIGTERM) により JVM はシャットダウンします。したがって、 アプリケーション・シグナル・ハンドラーでは、JVM を必要としなくなった場合を除き、 リカバリーを試みるべきではありません。
Runtime Environment にはシグナル・チェーニングが含まれています。シグナル・チェーニングにより、JVM は、独自のシグナル・ハンドラーをインストールするネイティブ・コードとの、より効率的な相互操作が可能となります。
シグナル・チェーニングにより、アプリケーションでは、システム・ライブラリーの前に共用ライブラリー libjsig.so に リンクしてロードすることが可能になります。libjsig.so ライブラリーにより、signal()、sigset()、および sigaction() などの呼び出しが確実にインターセプトされ、それらのハンドラーが JVM のシグナル・ハンドラーを置き換えることがなくなります。代わりに、これらの呼び出しは、新しいシグナル・ハンドラーを保管するか、または JVM がインストールしたハンドラーの後にそれらを「チェーニング」します。後で、これらのシグナルのいずれかが生じ、JVM をターゲットとしたものではないことが分かった場合、プリインストールされたハンドラーが起動します。
sigaction() を使用するシグナル・ハンドラーをインストールしている場合、JVM がシグナルを使用するときに、一部の sa_flags は見ることができません。これらは、以下のものです。
libjsig.so ライブラリーも、アプリケーションから JVM シグナル・ハンドラーを隠します。このため、JVM が開始した後で行われた signal()、sigset()、および sigaction() などの呼び出しでは、JVM のシグナル・ハンドラーへの参照を戻すことがなくなりますが、JVM の開始前にインストールされたハンドラーがあれば、代わりにそれを戻します。
libjsig.so を使用するには、以下のようにします。
gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.cまたは
export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash and ksh) setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)
環境変数 JAVA_HOME は、SDK の場所 (例えば /opt/ibm/java-i386-60/) に設定してください。
libjsig.a を使用するには、以下のようにします。
cc_r -q64 <other compile/link parameter> -L/opt/ibm/java-i386-60/jre/bin -ljsig -L/opt/ibm/java-i386-60/jre/bin/j9vm -ljvm java_application.c
ネイティブ・プログラムが 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 のどちらで実行しているかを判別し、適切なライブラリーを選択します。
SDK でネイティブ・アプリケーションをコンパイルおよびリンクするには、次のコマンドを使用します。
gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<arch>/j9vm -ljvm -ldl -lpthread <JNI program filename>-ljvm
オプションは、libjvm.so が、JVM を実装する共用ライブラリーであることを指定します。 -lpthread オプションは、ネイティブ pthread サポートを使用することを指示します。pthread ライブラリーとリンクしないと、 JNI プログラムの実行時にセグメンテーション障害 (シグナル SIGSEGV) が発生する可能性があります。
ブロック化コネクターのスレッド・レベルのリカバリーをサポートするため、IBM 固有の新規 SDK クラスが com.ibm.jvm パッケージに 4 つ追加されました。新しいクラスは、core.jar 内に圧縮されています。
これらのクラスにより、ネットワーキング呼び出し、あるいは同期呼び出しでブロック化されたスレッドのブロックを解除できます。 これらのクラスを使用しない場合、アプリケーションは、 個別のブロックされたスレッドに割り込みをかけるのではなく、プロセス全体を終了させる必要があります。
これらのクラスは以下のとおりです。
InterruptibleLockContext および InterruptibleIOContext は、両方とも現行スレッドを参照することによって機能します。 このため、InterruptibleThread を使用しない場合、これらの新しいクラスを使用するためには、java.lang.Thread を拡張するユーザー独自のクラスを準備する必要があります。
これらのクラスの Javadoc は、SDK に付属しており、docs/content/apidoc ディレクトリーに収録されています。
大規模ページをサポートするシステムでこのサポートを使用可能にするには、 -Xlp オプションを指定して Java を始動します。
大規模ページは、多くのメモリーを割り振って頻繁にそのメモリーにアクセスする アプリケーションのパフォーマンスを向上させるために使用するものです。 大規模ページによるパフォーマンスの向上は、 主に Translation Lookaside Buffer (TLB) のミスの数を減らすことによって実現します。 TLB は、より大きな仮想メモリー範囲をマップし、それにより、この向上をもたらします。
Java が大規模ページを使用できるためには、大規模ページ・サポートがカーネルで利用可能で、有効にされていなければなりません。
大規模ページのメモリー割り振りを構成するには、 まず実行されているカーネルが大規模ページをサポートしていることを確認します。 ファイル /proc/meminfo に、以下の行が含まれていることを確認してください。
HugePages_Total: <number of pages> HugePages_Free: <number of pages> Hugepagesize: <page size, in kB>
使用可能なページの数とそのサイズは、ディストリビューションによって異なります。
大規模ページ・サポートがカーネルで利用可能でない場合、これらの行は /proc/meminfo ファイルに存在しません。この場合には、大規模ページのサポートを含む新しいカーネルをインストールしてください。
大規模ページ・サポートが利用可能だが有効にされていない場合、HugePages_Total は 0 になります。 この場合は、管理者が大規模ページ・サポートを有効にする必要があります。 詳しくは、オペレーティング・システムのマニュアルを確認してください。
JVM が大規模ページを使用するためには、システムで、十分な数の連続した大規模ページが使用可能でなければなりません。 十分なページが使用可能であっても、大規模ページを割り振れない場合、大規模ページが連続していない可能性があります。 ブートアップ時の大規模ページ数を構成すると、それらが連続して作成されます。
大規模ページの割り振りは、JVM が root アクセス権を持つ場合にのみ、正常終了します。 大規模ページを使用するには、Java を root で実行するか、Java ランチャーの suid ビットを設定します。
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 では、SeaMonkey、Mozilla、 および Mozilla Firefox がサポートされています。
ブラウザー | サポートされるバージョン |
---|---|
Mozilla | 1.7.12, 1.8 |
Firefox | 1.5, 2.0 |
ブラウザー | サポートされるバージョン |
---|---|
Mozilla | 1.6 |
|SeaMonkey | |1.0.8 |
ブラウザーのこれ以降のマイナー・リリースもサポートされています。
Java Plug-in をインストールするには、ブラウザーのプラグイン・ディレクトリーへのシンボリック・リンクを作成します。
Java Plug-in は、Mozilla の Open JVM Integration イニシアチブが基本になっており、大半の Mozilla 製品および派生品 (Firefox など) と組み合わせて使用されます。
以下に、いくつかの一般的なブラウザーに Plug-in をインストールするための手順を示します。
JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。
Mozilla バージョン 1.4 以降のみがサポートされます。
cd /usr/local/mozilla/plugins/
cd $HOME/.mozilla/plugins
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.soここで、<arch> は、システムのアーキテクチャーを表します。
JavaPlug-in が使用可能で有効になっていることを確認するには、Mozilla で「ヘルプ」 -> 「Plug-in について」を選択します。
JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。
以下の手順を実行すると、すべてのユーザーが Java Plug-in を使用できるようになります。
cd /usr/local/mozilla-firefox/plugins/
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .ここで、<arch> は、システムのアーキテクチャーを表します。
JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。
特定のブラウザーによる制約のために、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 $HOME/<filename>.html
ここで、filename は HTML ファイルの名前です。
Web ページでアプレット・ビューアーを呼び出すには、シェル・プロンプトで次のように入力します。
appletviewer http://java.sun.com/applets/NervousText/example1.html
アプレット・ビューアーは、<META> タグの charset オプションは認識しません。アプレット・ビューアーがロードするファイルが、システム・デフォルトとしてエンコードされていないと、I/O 例外が発生する可能性があります。この例外を避けるには、appletviewer を実行するときに、 -encoding オプションを使用します。例えば、次のようにします。
appletviewer -encoding JISAutoDetect sample.html
アプレットをデバッグするには、アプレット・ビューアーの -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 アプリケーション・キャッシュに保管されます。
Java Web Start バージョン 6 は、.rpm または .tgz パッケージによる Java のインストール時に、自動的にインストールされます。 Java を .tgz パッケージから解凍した場合、jre/lib/javaws/updateSettings.sh シェル・スクリプトを実行して、システムの .mailcap および .mime.types ファイルを更新してください。
Web Start は、以下のいくつかの異なる方法で起動できます。
javaws <URL>ここで、<URL> は .jnlp ファイルの場所です。
/opt/ibm/java-i386-60/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 Linux が必要です。 SDK for Linux ソフトウェアには Runtime Environment が含まれます。ただし、 ユーザーが SDK for Linux ソフトウェアをインストール済みであることを前提にすることはできません。
SDK for Linux ソフトウェアのライセンスでは、 SDK のファイルをアプリケーションとともに再配布することが許可されません。 ライセンス交付を受けた SDK for Linux がターゲット・マシンにインストールされていることを確認してください。
クラス・データの共用によって、複数の 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 セキュリティーの許可によって制限されます。共用クラス・キャッシュは、 groupAccess コマンド行サブオプションが使用された場合を除いて、 デフォルトでユーザー・アクセスで作成されます。クラス・データの共用を登録しているクラス・ローダーのみが、共用クラス・キャッシュを更新できます。
|キャッシュ・メモリーは、メモリー・ページ保護機能により偶発的/意図的な破損から保護されています。これは絶対に破損しないことを保証するものではありません。これは、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 です。指定できるキャッシュのサイズは、システムに使用可能な物理メモリーおよびページング・スペースの量によって制限されます。
クラスを共用するためのキャッシュは、System V IPC 共用メモリー・メカニズムを使用して割り振られます。
プロセスの仮想アドレス・スペースは、 共用クラス・キャッシュと Java ヒープで共用されるため、Java ヒープの最大サイズを増やすと、作成可能な共用クラス・キャッシュのサイズが減ります。
キャッシュ・サイズは、SHMMAX の設定により制限されます。 これは、割り振り可能な共用メモリーの量を制限します。 これらの設定は、/proc/sys/kernel/shmmax ファイルにあります。SHMMAX は通常 30 MB に設定されます。
バイトコード・データを変更可能な 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 ビットのキャッシュがリストされます。
共用クラス・キャッシュは、 システムに存在するキャッシュに関する識別情報を保管するためのディスク・スペースを必要とします。 この情報は、/tmp/javasharedresources に保管されます。 識別情報ディレクトリーが削除された場合、JVM はシステム上の共用クラスを識別できないため、 キャッシュを再作成する必要があります。ipcs コマンドを使用して、JVM またはアプリケーションによって使用されるメモリー・セグメントを表示できます。
共用クラス・キャッシュを使用するために、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) は、IA32、PPC32/PPC64 および AMD64/EM64T プラットフォームの Runtime Environment for Linux で使用するために提供されているオプションのパッケージです。 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 がインストール済みであることを確認してください。
もともと RPM パッケージを使用して Java をインストールしている場合は、 Java Communications API を RPM ファイルからインストールしてください。Java Communications API を RPM パッケージからインストールするには、RPM ファイルからの Java Communications API のインストールを参照してください。
Java Communications API を圧縮ファイルからインストールするには、以下のようにします。
tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz
ここで、<arch> はアーキテクチャー (i386、x86_64、ppc、または ppc64) を表します。
Java Communications API をインストールする前に、SDK または Runtime Environment がインストール済みであることを確認してください。
もともと RPM パッケージを使用して Java をインストールしている場合は、 Java Communications API を RPM ファイルからインストールしてください。
rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpmJava Communications API は、/opt/ibm/java-i386-60/ ディレクトリー構造の内部にインストールされます。
デフォルトでは、Java Communications API ファイルは、/opt/ibm/java-i386-60/ ディレクトリーにインストールされます。 これらのファイルとその構造は以下のとおりです。
Java Communications API をインストールしたら、シリアル・ポートとパラレル・ポートのアクセス・モードを変更して、ユーザーがこれらのデバイスにアクセスできるようにする必要があります。
必要なデバイスに対する読み取りおよび書き込みアクセス権限をユーザーに与える必要があります。 root でログオンして、 該当する以下のコマンドを使用してください。
chmod 660 /dev/ttyS0 (別名 シリアル・ポート COM1) chmod 660 /dev/lp0 (別名 パラレル・ポート LPT1) chmod 660 /dev/ttyS1 (別名 シリアル・ポート COM2) chmod 660 /dev/ttyS2 (別名 シリアル・ポート COM3) chmod 660 /dev/ttyS3 (別名 シリアル・ポート COM4)
特定のユーザーをデバイスが存在するグループに追加します。例えば、SUSE システムでは、デバイスは、uucp グループにあります。この場合、 ユーザーは uucp グループに追加されると、そのデバイスへのアクセス権も得られます。
必要に応じてそのほかのポートのアクセス・モードを変更します。
ファイル javax.comm.properties を使用すると、Java Communications API に対して使用可能にするデバイスの接頭部と、それらのデバイスがパラレルかシリアルかを指定できます。 ポート番号は、すべてのデバイスに順番に割り振られます。
例えば、/dev/ttyS=PORT_SERIAL と指定していて、/dev/ttyS0 と /dev/ttyS1 の 2 つのデバイスが存在する場合、これらのデバイスは COM1 と COM2 に割り振られます。
USB シリアル・コネクターを使用する場合は、javax.comm.properties ファイルの /dev/ttyUSB=PORT_SERIAL という行のコメントを外してください。 デバイス /dev/ttyUSB0 と /dev/ttyUSB1 が存在していて、COM1 と COM2 がすでに定義済みの場合、USB シリアル・デバイスは次の番号のポートである COM3 と COM4 に 割り振られます。
多くの ThinkPad では BIOS によってデフォルトで使用不可にされているシリアル・ポートがあります。 現時点では、Linux でこのポートを使用可能にする方法はありません (ポートが BIOS で使用不可に設定されている場合、tpctl パッケージではポートを使用可能に設定できません)。
BIOS でポートを使用可能に設定するには、IBM ThinkPad のダウンロード・サイトで入手可能な DOS バージョンの ThinkPad 構成ユーティリティーを使用する必要があります。ThinkPad 構成ユーティリティーを使用するには、ブート可能な DOS ディスケットが必要です。 ThinkPad 構成ユーティリティーは、インストール・オプションによっては Windows(R) の ThinkPad ユーティリティーの一部としてインストールされている可能性があることに注意してください。このユーティリティーは、Windows のコマンド・プロンプトから実行できます。
Windows の場合に提供される ThinkPad 構成アプリケーションには、シリアル・ポートとパラレル・ポートを 使用可能または使用不可に設定するオプションがありますが、このオプションでは BIOS での設定を変更できません。 このため、このアプリケーションを Windows で使用する場合はポートを使用できますが、Linux を使用してシステムをリブートすると、ポートは使用できません。
Java Communications API を使用して印刷をするときは、プリンターで「用紙送り」、「継続」、または類似したボタンを押す必要があります。
Java Communications API をアンインストールする場合に使用する手順は、インストール可能な Red Hat Package Manager (RPM) パッケージをインストールしているか、Tape Archive (TAR) 圧縮パッケージをインストールしているかによって異なります。
RPM パッケージを使用して、Java Communications API をアンインストールします。
rpm -e ibm-javacomm-3.0-0.0あるいは、kpackage や yast2 などのグラフィック・ツールを使用することもできます。
TAR 圧縮パッケージをインストールした場合に、Java Communications API をアンインストールするには、以下の手順を実行します。
以下のファイルを、インストールしたディレクトリーから削除します。
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 アプリケーションを起動することができます。設定オプションを変更するには、ユーザーのホーム・ディレクトリーにある構成ファイル .java/.deployment/.deployment.properties を編集する必要があります。このファイルは、編集する前にバックアップをとってください。 Java アプリケーション・キャッシュ・ビューアーで指定できる設定がすべて、構成ファイルにあるわけではありません。
本書に関するご意見は、以下の連絡手段のいずれかを使用してご連絡ください。なお、これらの連絡手段は、技術的な問い合わせに答えるためではなく、資料に対するご意見のみをお聞きするために設けてあることを、ご了承ください。
ご意見の送り先は次のとおりです。
ただし、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 Linux の既知の制限。
問題の診断方法について詳しくは、「Diagnostics Guide (英語)」(http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html) を参照してください。
「ノード・メモリー・インターリービング (Node memory interleaving)」の BIOS 設定は「使用不可 (DISABLED)」に設定してください。 そうでないと、Java のクラッシュやハングを含む、予測不能な結果が発生する可能性があります。この指示は、AMD の推奨と一致しています。
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 エンジンをダウンロードしてください。
一般的でない長さの DSA 鍵ペアの作成は、低速なマシンでは非常に長い時間を要します。 十分な時間が経過すれば完了するので、遅れてもハングしたと解釈しないでください。DSA 鍵生成アルゴリズムは、標準の鍵の長さ (例えば、512、1024) を他より迅速に生成するよう、最適化されています。
ネイティブ・プログラムでは、JNI_VERSION_1_1(0x00010001) インターフェースで VM を作成できません。JNI_CreateJavaVM() を呼び出して、JNI_VERSION_1_1(0x00010001) のバージョンを渡すことはできません。渡すことが可能なバージョンは次のとおりです。
作成される VM は、存在する Java ライブラリー (つまり、1.2.2、1.3.x、1.4.x、 5.x、6.x) によって決まります。渡される JNI インターフェースのバージョンによって示唆されるライブラリーによってではありません。
インターフェース・バージョンは、ネイティブ・コードで使用可能な関数の種類以外の VM の動作領域に影響を与えることはありません。
ウィンドウ・マネージャーが、Java キーボード・ショートカットの一部をオーバーライドする場合があります。オーバーライドされた Java キーボード・ショートカットを使用する必要がある場合は、オペレーティング・システムのマニュアルを参照し、ウィンドウ・マネージャーのキーボード・ショートカットを変更してください。
X Window System では、255 より上のファイル記述子を使用できません。JVM は開いている jar ファイルのファイル記述子を保持するため、X でファイル記述子を使い果たす可能性があります。回避策として、JAVA_HIGH_ZIPFDS 環境変数を設定し、jar ファイル用に大きな数のファイル記述子を使用するよう JVM に指示することができます。
JAVA_HIGH_ZIPFDS 環境変数を使用するには、0 から 512 の間の値に設定します。設定後 JVM は、1024 までのファイル記述子を使用して、最初の jar ファイルを開きます。例えば、プログラムで 300 個の jar ファイルをロードする場合は、次のように設定します。
export JAVA_HIGH_ZIPFDS=300
これによって、最初の 300 個の jar ファイルは、ファイル記述子として 724 から 1023 までを使用してロードされます。それ以後に開かれる jar ファイルは、すべて通常範囲で開かれます。
K Desktop Environment (KDE) を実行している場合は、Linux アプリケーションと Java アプリケーションの間で、システム・クリップボードを使用して 2 バイト文字セット (DBCS) の情報をコピーできない可能性があります。
SLES9および以降のディストリビューションでは、デフォルトのスレッド化ライブラリーが NPTL になっており、これにより Java スレッドがネイティブ・スレッドとしてインプリメントされます。それ以前のディストリビューションでは、デフォルトのスレッド化ライブラリーが LinuxThreads になっており、この場合はスレッドが新規プロセスとしてインプリメントされます。Java スレッドの数がプロセスの許容最大数を超えると、プログラムがハングする可能性があります。
使用可能なスレッドの最大数は、次の中の最低値によって決まります。
ただし、スレッドの最大数に達する前に、仮想ストレージを使い果たす可能性があります。
このプラットフォームでは、ユーザー・モードの CPU 時間とシステム・モードの CPU 時間を区別する方法はありません。ThreadMXBean.getThreadUserTime()、ThreadMXBean.getThreadCpuTime()、ThreadMXBean.getCurrentThreadUserTime()、および ThreadMXBean.getCurrentThreadCpuTime() はすべて、必要なスレッドの合計 CPU 時間を戻します。
Alt キーを含む KeyEvent の結果は、Linux のウィンドウ・マネージャーの種類によって異なる場合があります。 また、他のオペレーティング・システムの結果とも異なります。デフォルト設定を使用する場合、KWin ウィンドウ・マネージャーでは Ctrl+Alt+A によって KeyEvent が生成されるのに対し、Metacity ウィンドウ・マネージャーでは Ctrl+Alt+A はキー・イベントを生成しません。
Linux X Window System では、 keymap が 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) および 113 0xffea (Alt_R) 0xffe8 (Meta_R) に設定されます。この設定は、シェル・プロンプトで次のように入力することによって確認できます。
xmodmap -pk
そのため SDK は、Meta および Alt キーが同時に押されたとみなします。回避策として、シェル・プロンプトで次のように入力することにより、Meta_x マッピングを除去できます。
xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"
この回避策を行うと、同じディスプレイ上で実行している他の X-Windows アプリケーションが除去された Meta キーを使用している場合には、それらのアプリケーションに影響を与える可能性があります。
JNI アプリケーションからの JNI_CreateJavaVM() の呼び出しが原因で、セグメンテーション障害 (シグナル SIGSEGV) が起きる場合があります。この障害を回避するために、 オプション -lpthread を指定して JNI プログラムを再ビルドしてください。
並行スレッドを数多く実行していると、次の警告メッセージが表示される場合があります。
java.lang.OutOfMemoryError
これは、マシンのシステム・リソースが不足していることを示します。メッセージは、次の理由によって生成される可能性があります。
対応するシステム・リソースが増加するように、システムの調整を試みてください。
Linux マシンで Java AWT または Swing アプリケーションを実行し、別のマシンに表示をエクスポートするときに、X クライアント・マシンにロードされているフォント・セットと X サーバー・マシンにロードされているフォント・セットが異なっていると、ダイアログを表示するときに問題が発生します。この問題を回避するには、両方のマシンに同じフォントをインストールします。
ご使用のシステム・ロケールで UTF-8 エンコード方式を使用している場合は、一部の SDK ツールによって sun.io.MalformedInputException がスローされる可能性があります。 システムで UTF-8 エンコード方式が使用されているかどうかを確認するには、LANG や LC_ALL などのロケール固有の環境変数を調べ、サフィックスが 『.UTF-8』 になっているかどうかを見ます。この sun.io.MalformedInputException を受け取った場合は、7 ビット ASCII 範囲 (0x00 から 0x7f) に入っておらず、Java Unicode 文字リテラルとして表現されていない文字を、Java Unicode 文字リテラル (例えば、「¥u0080」) に変更します。この問題の回避策として、ロケール固有の環境変数から 「.UTF-8」サフィックスを除去することができます。例えば、マシンのデフォルト・ロケールが「en_US.UTF-8」の場合は、LANG を「en_US」に設定します。
クロスプラットフォーム環境で AMI と xcin を使用する場合 (例えば、32 ビットと 64 ビットのシステムの間や、ビッグ・エンディアンとリトル・エンディアンのシステムの間で表示をエクスポートする場合) は、問題が発生する場合があります。この種の問題が発生した場合は、AMI と xcin の最新バージョンにアップグレードしてください。
中国語、韓国語、および日本語の RHEL4 ユーザーの場合のみ
デフォルトでは XIM サーバーがインストールされません。DBCS 文字を Java アプリケーションに入力するには、iiimf-x や kinput2 などの XIM サーバー・パッケージをインストールしてください。
中国語、韓国語、および日本語の RHEL4 ユーザーの場合のみ
Internet/Intranet Input Method Framework (IIIMF) を使用する場合は、Red Hat Enterprise Linux 4 Update 2 以降に付属する IIIMF パッケージを使用してください。http://www.redhat.com にアクセスし、Red Hat にお問い合わせください。
(zSeries 64 ビットのみ) IIIMF で障害が発生したり、始動できなかったりする場合があります。この問題を解決するには、最新の IIIMF パッケージにアップグレードしてください。
(PPC、s390、または s390x の中国語 (繁体字) のみ) IIIMF が機能しない場合があります。この問題を解決するには、iiimf-le-xcin-0.1.7-13.EL4 以降を使用してください。
(PPC、s390、または s390x の中国語 (簡体字) のみ) IIIMF が正しく機能しない場合があります。この問題を解決するには、RHEL4 Update 5 以降に含まれる IIMF パッケージを使用してください。
中国語 (簡体字) の RHEL4 ユーザーの場合のみ
zh_CN.GB18030 ロケールは、RHEL4 の xlib によってサポートされていません。xterm を使用しても、Input Method Server をアクティブ化して GB18030 文字を入力することはできません。代わりに、zh_CN.UTF8 ロケールを使用してください。GB2312、GBK、または GB18030 でエンコードされたレガシー・プログラムやデータを使用しており、RHEL4 にマイグレーションする場合は、zh_CN.UTF8 ロケールが設定されている RHEL4 でアプリケーションが正常に実行され、データが正しく表示されるようにするため、iconv によってそれらのデータを前処理して UTF-8 エンコード方式に変換する必要があります。
この制限は、RHEL4 U3 では解決されています。
RHEL4 で xcin がハングする場合があります。この問題を解決するには、/etc/chinese/xcin/xcinrc ファイルで ICCHECK_DISABLE を「はい」に設定します。
64 ビット環境のみ
xcin (中国語 (繁体字) XIM サーバー) を使用する RHEL4 では、64 ビット環境 (AMD64 や zSeries 64 ビット・プラットフォームなど) で動作する Java でのセグメンテーション障害など、予期しない振る舞いが生じる場合があります。この問題を解決するには、最新の xcin パッケージにアップグレードしてください。
RHEL4 のみ
IIMF (Internet Intranet Input Method Framework) を使用して DBCS 文字を入力するときに、フォーカス変更問題が生じる可能性があります。この問題は、アクティブな入力コンポーネントを最小化するときに発生します。 コンポーネントを復元すると、入力方式が SBCS に切り替わります。 DBCS は、その後手動でもう一度アクティブ化する必要があります。
次のコンポーネントの場合に、このフォーカス変更問題が発生します。
RHEL4、および SLES9 のみ
日本語、中国語、および韓国語のユーザーの場合は、Web ブラウザーの Java アプレットのテキスト・コンポーネントに、XIM を使用して各言語の文字を入力することができません。この制限は、XEmbed が X11 ライブラリー・ファイルへの修正を必要とすることに起因します。この状況を回避するには、-Dsun.awt.noxembed=true システム・パラメーターを指定して XEmbed を無効にします。このオプションは、コントロール・パネルを使用して設定できます。
この制限は、RHEL4 U3 および SLES9 SP3 では解決されています。
Intel 32 ビット・プラットフォームのみ
アラビア語テキストのユーザーが、Matrox ビデオ・カードが搭載された、アクセラレーションが有効な Linux を使用すると、drawString を使用して大きなフォントを表示するときに文字がゆがむ可能性があります。この問題は、それらのカードのドライバーに起因します。回避策としては、デバイスのアクセラレーション機能を無効にすることを提案します。
Intel 32 ビット・プラットフォームのみ
SLES 9 NPTL では、パラレル・ポート・ドライバーによってカーネルがクラッシュし、Java スレッドが動作を停止します。JVM は、ガーベッジ・コレクションのためスレッドを中断しようとするときにこのクラッシュを検出し、次いでコア・ファイルとメッセージ「JVMLH030: threads are disappearing when trying to suspend all threads」を生成してクラッシュします。
SUSE Bugzilla レポート 47947 が、この問題に対して報告されています。このバグは、SLES 9 Service Pack 1 では修正されています。
PPC プラットフォームのみ
Java コードで JNI 呼び出しが使用されていて、いずれかの呼び出しに浮動小数点または倍精度パラメーターが 8 個より多くある場合は、C コードを GNU C Compiler (GCC) の gcc-2.95.3 Free Software Foundation (FSF) レベルでコンパイルする必要があります。
PPC プラットフォームのみ
JavaComm パッケージでは、SLES 9 GA および SP1 カーネルでのパラレル・ポート・オペレーションをサポートできません。この制限は、SP2 カーネルでは解決されています。SUSE Bugzilla 番号は 50028 です。
PPC 64 ビット・プラットフォームのみ
デフォルトの gcc クロス・コンパイラー (バージョン 3.2-49) では、いくつかのエラーが発生します。共用ライブラリー libFileStat.so を生成するには、次のコマンドを実行します。
/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c
ここで、<SDK_PATH> はインストールされている SDK ディレクトリーへのパスです。
zSeries プラットフォームのみ
現行ディストリビューションの Linux カーネルは Internet Protocol バージョン 6 (IPv6) をサポートしますが、IPv6 を使用すると問題が発生する場合があります。Java による IPv6 のサポートはこのリリースに組み込まれていますが、java コマンドで -Djava.net.preferIPv4Stack=true オプションを指定し、このサポートをオフにすることをお勧めします。IPv6 に完全対応したカーネルをインストールする場合は、このオプションは不要です。
zSeries 64 ビット・プラットフォームのみ
中国語および台湾語の入力方式サーバー (xcin) はテストされていません。
1 つ以上の GNOME ライブラリーが使用できないため、Java Desktop API が機能しない場合があります。
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、iSeries、pSeries、および zSeries は、International Business Machines Corporation の米国およびその他の国における商標です。
Intel は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。
Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。