*IBM SDK for Linux platforms, Java Technology Edition, バージョン 6

SDK およびランタイム・ガイド



IBM 発行のマニュアルに関する情報のページ

http://www.ibm.com/jp/manuals/

こちらから、日本語版および英語版のオンライン・ライブラリーをご利用いただけます。 また、マニュアルに関するご意見やご感想を、上記ページよりお送りください。今後の参考にさせていただきます。

(URL は、変更になる場合があります)

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。



原 典:


IBM SDK for Linux platforms, Java Technology Edition, Version 6

SDK and Runtime Guide

発 行:
日本アイ・ビー・エム株式会社

担 当:
ナショナル・ランゲージ・サポート

Copyright International Business Machines Corporation 2003, 2007. All rights reserved.

(C) Copyright IBM Japan 2007

目次

前書き
概説
規則
バージョンの互換性
他の IBM JVM からのマイグレーション
System z のサポート対象ハードウェア
SDK および Runtime Environment のコンテンツ
Runtime Environment のクラスおよびツール
SDK ツールおよび参照情報
SDK and Runtime Environment のインストールおよび構成
SDK のアップグレード
Red Hat Enterprise Linux (RHEL) 4 へのインストール
Red Hat Enterprise Linux (RHEL) 5 へのインストール
RHEL 5 上の SELinux を使用した Java の実行
64 ビット・アーキテクチャーへの 32 ビット SDK のインストール
RPM ファイルからのインストール
.tgz ファイルからのインストール
JPackage 互換フォーマットの使用
SDK and Runtime Environment for Linux の構成
パスの設定
クラスパスの設定
SDK and Runtime Environment for Linux のアンインストール
Red Hat Package Manager (RPM) パッケージのアンインストール
Tape Archive (TAR) 圧縮パッケージ のアンインストール
Java アプリケーションの実行
java および javaw コマンド
バージョン情報の取得
Java オプションとシステム・プロパティーの指定
標準オプション
java コマンドのグローバリゼーション
Just-In-Time (JIT) コンパイラー
JIT の使用不可化
JIT の使用可能化
JIT が使用可能かどうかを判別する
ガーベッジ・コレクション・ポリシーの指定
ガーベッジ・コレクションのオプション
休止時間
休止時間の削減
ヒープがフルの環境
ユーロ記号のサポート
フォールバック・フォント構成ファイル
| |
インドおよびタイ語の入力方式の使用
SDK を使用した Java アプリケーションの開発
| |
XML の使用
| |
XL-TXE-J のマイグレーション
| |
XML 参照情報
Java アプリケーションのデバッグ
Java Debugger (JDB)
アプリケーションが 32 ビットまたは 64 ビットのどちらの JVM で実行されているかを判別する
JVM のシグナルの処理方法
JVM が使用するシグナル
ネイティブ・コード・ドライバーをシグナル・チェーニング・ライブラリーにリンクする
JNI アプリケーションの作成
ブロック化コネクターのスレッド・レベルのリカバリーのサポート
大規模ページのメモリー割り振りの構成
CORBA サポート
ORB をトレースするためのシステム・プロパティー
ORB を調整するためのシステム・プロパティー
ORB の Java セキュリティー権限
ORB 実装クラス
RMI over IIOP
RMI の Connection Handler Pool の実装
拡張 BigDecimal
Plug-in、アプレット・ビューアー、および Web Start
(Linux IA 32 ビットおよび PPC32 のみ) Java Plug-in の使用
サポートされるブラウザー
Java Plug-in のインストールおよび構成
共通 Document Object Model (DOM) サポート
DBCS パラメーターの使用
アプレットの処理
アプレット・ビューアーでアプレットを実行する
アプレット・ビューアーでアプレットをデバッグする
(Linux IA 32 ビット、PPC32、および PPC64 のみ) Web Start の使用
Web Start の実行
(Linux IA 32 ビットのみ) WebStart Secure の静的バージョン管理
Java アプリケーションの出荷
JVM 間でのクラス・データの共用
クラス・データ共用の概要
クラス・データ共用の使用可能化と構成
キャッシュの作成、読み込み、モニター、および削除
パフォーマンスとメモリーの消費
クラス・データ共用を使用する際の考慮事項と制限
キャッシュ・サイズの制限
実行時バイトコード変更
オペレーティング・システムの制限
SharedClassPermission の使用
カスタム・クラス・ローダーの共用クラスへの適応
Java Communications API (JavaComm) の使用
圧縮ファイルからの Java Communications API のインストール
RPM ファイルからの Java Communications API のインストール
Java Communications API ファイルの場所
シリアル・ポートとパラレル・ポートのアクセス・モードの変更
javax.comm.properties ファイルでのデバイスの指定
IBM ThinkPad でのシリアル・ポートの使用可能化
Java Communications API での印刷に関する制限
Java Communications API のアンインストール
Red Hat Package Manager (RPM) パッケージのアンインストール
Tape Archive (TAR) 圧縮パッケージのアンインストール
Java Communications API ドキュメンテーション
独立系ソフトウェア・ベンダーのサービスおよびサポート
アクセシビリティー
Swing での JComboBox コンポーネントのキーボードによる探索
Web Start のアクセシビリティー (Linux IA 32 ビット、PPC32、および PPC64 のみ)
本書に関するご意見
付録A. 非標準オプション
付録B. 既知の制限
特記事項
商標

前書き

本書には、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 間で互換性を持ちます。

他の IBM JVM からのマイグレーション

バージョン 5.0 から、IBM Runtime Environment for Linux には、新しいバージョンの IBM Virtual Machine for Java と Just-In-Time (JIT) コンパイラーが含まれています。

以前の IBM Runtime Environment からマイグレーションする場合は、以下のことに注意してください。

System z のサポート対象ハードウェア

System z31-bit SDK および 64-bit SDK と Runtime Environment は、System z9(TM) および zSeries(R)ハードウェア上で稼働します。

SDK および Runtime Environment は、以下のサーバーまたは同等のサーバー上で稼働します。

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 のクラスおよびツール

標準的な Runtime Environment と一緒に使用できるクラスおよびツールのリストです。

SDK ツールおよび参照情報

標準 SDK に含まれているツールと参照情報のリストです。

以下のツールは SDK の一部として /opt/ibm/java-i386-60/bin ディレクトリーに配置されています。
appletviewer (Java アプレット・ビューアー)
Web ブラウザーの外部でアプレットをテスト、実行します。
apt (注釈処理ツール)
検査中の指定された一連のソース・ファイル内に存在する注釈に基づいて、注釈プロセッサーを検索および実行します。
extcheck (Extcheck ユーティリティー)
ターゲット JAR ファイルと現在インストール済みの拡張 JAR ファイル間のバージョンの矛盾を検出します。
(Linux IA 32 ビット、PPC32、および PPC64 のみ) HtmlConverter (Java Plug-in HTML Converter)
アプレットを含む HTML ページを Java Plug-in を使用できるフォーマットに変換します。
idlj (IDL から Java コンパイラーへ)
指定の IDL ファイルから Java バインディングを生成します。
ikeycmd (iKeyman コマンド行ユーティリティー)
鍵、証明書、および認証要求をコマンド行で管理できます。詳しくは、 付随する「Security Guide (英語)」および http://www.ibm.com/developerworks/java/jdk/security を参照してください。
jar (Java アーカイブ・ツール)
複数ファイルを単一の Java Archive (JAR) ファイルに結合させます。
jarsigner (JAR 署名および検証ツール)
JAR ファイルの署名を生成し、署名付き JAR ファイルの署名を検証します。
java-rmi.cgi (HTTP-to-CGI 要求転送ツール)
RMI-over-HTTP 要求を受信し、任意のポートで listen している RMI サーバーにそれらを転送します。
javac (Java コンパイラー)
Java プログラミング言語で書かれたプログラムをバイトコード (コンパイル済み Java コード) に コンパイルします。
javadoc (Java ドキュメンテーション・ジェネレーター)
Java ソース・ファイルから API ドキュメンテーションの HTML ページを生成します。
javah (C ヘッダーおよびスタブ・ファイル・ジェネレーター)
これにより、ネイティブ・メソッドを Java プログラミング言語で書かれたコードに関連付けることができます。
javap (クラス・ファイルの逆アセンブラー)
コンパイル済みファイルを逆アセンブルし、バイトコード表記を表示できます。
javaw (Java インタープリター)
java コマンドと同様の方法で Java クラスを実行しますが、コンソール・ウィンドウは使用しません。
(Linux IA 32 ビット、PPC32、および PPC64 のみ) javaws (Java Web Start)
Java アプリケーションの配置と自動保守を可能にします。詳しくは、『Web Start の実行』を参照してください。
jconsole (JConsole モニターおよび管理ツール)
GUI を使用してローカル JVM とリモート JVM をモニターします。JMX に準拠しています。
jdb (Java デバッガー)
Java プログラムのデバッグに役立ちます。
jdmpview (クロスプラットフォーム・ダンプ・フォーマッター)
ダンプを分析します。詳しくは、「Diagnostics Guide (英語)」を参照してください。
native2ascii (Native-To-ASCII コンバーター)
ネイティブ・エンコード・ファイルを Latin 1 または Unicode またはその両方にエンコードされている 文字を含む ASCII ファイルに変換します。
rmic (Java Remote Method Invocation (RMI) スタブ・コンバーター)
リモート・オブジェクトのスタブ、スケルトン、およびタイを生成します。Internet Inter-ORB Protocol (RMI-IIOP) 上の RMI サポートも含みます。
schemagen
Javaクラスで参照される名前空間ごとにスキーマ・ファイルを作成します。
serialver (直列化バージョン・コマンド)
新しいクラスへのコピーに適切な形式で、1 つ以上のクラスの serialVersionUID を戻します。
wsgen
JAX-WS Web サービスで使用する JAX-WS 移植可能成果物を生成します。
wsimport
WSDL ファイルから JAX-WS 移植可能成果物を生成します。
xjc
XML スキーマ・ファイルをコンパイルします。
インクルード・ファイル
JNI プログラムの C ヘッダー
デモ
demo ディレクトリーには、ユーザーが使用できるサンプル・ソース・コード、デモ、アプリケーション、 およびアプレットが入った多くのサブディレクトリーがあります。|バージョン 6 以降、RMI-IIOP デモは SDK に含まれていません。
著作権
SDK for Linux ソフトウェアの著作権表示。
ライセンス

ライセンス・ファイル /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>には、SDK for Linux ソフトウェアのご使用条件が含まれています (<locale> は使用するロケールの名前です。例えば en)。ご使用条件を 表示あるいは印刷するには、Web ブラウザーでこのファイルをオープンしてください。

SDK and Runtime Environment のインストールおよび構成

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) 4 へのインストール

SDK は共用ライブラリーに依存しますが、これらのライブラリーは、デフォルトでは Red Hat Enterprise Linux (RHEL) 用にインストールされません。

RHEL 4 では、これらのライブラリーを含む RPM は、次のとおりです。

RHEL 4 のインストール中にこれらのライブラリーを組み込むには、次のようにします。

  1. パッケージのデフォルト (Package Defaults)」画面で、「インストールするパッケージ・セットのカスタマイズ (Customize the set of packages to be installed)」を選択します。
  2. パッケージ・グループ選択 (Package Group Selection)」画面の「X Window システム (X Windows System)」の下で「詳細 (Details)」を選択し、xorg-x11-deprecated-libs が選択されていることを確認します。
  3. 開発 (Development)」オプションの下で、「レガシー・ソフトウェア開発 (Legacy Software Development)」を選択します。

Red Hat Enterprise Linux (RHEL) 5 へのインストール

SDK は共用ライブラリーに依存しますが、これらのライブラリーは、デフォルトでは Red Hat Enterprise Linux (RHEL) 用にインストールされません。

RHEL 5 では、これらのライブラリーを含む RPM は、次のとおりです。

RHEL 5 のインストール中にこれらのライブラリーを組み込むには、次のようにします。

  1. ソフトウェア選択画面で、「今すぐカスタマイズ (Customize now)」を選択します。
  2. 次の画面の左側のパネルで「基本システム (Base System)」を選択し、右側のパネルで「レガシー・ソフトウェア・サポート (Legacy Software Support)」を選択します。 これらを選択することにより、compat-libstdc++ パッケージがインストールされます。
  3. libXp パッケージが必要ですが、インストール GUI からインストール用に選択することはできません。インストールが完了したら、シェルを開いて Red Hat インストール・メディア上の libXpパッケージを見つけ、それをインストールしてください。 例えば、32 ビット Intel プラットフォームにインストールするには、rpm -i /media/cdrom/Server/libXp-1.0.0-8.i386.rpm を実行します。

RHEL 5 上の SELinux を使用した Java の実行

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』を参照してください。

64 ビット・アーキテクチャーへの 32 ビット SDK のインストール

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 ファイルからインストールするための手順です。

rpm ツールを使用して JVM をアップグレードするには、旧バージョンをすべてアンインストールする必要があります。JVM の 2 つのバージョンを別々の場所にインストールするには、rpm --force オプションを使用してバージョンの競合を無視するか、JVM を .tgz ファイルからインストールします。

  1. root でログオンしていること確認して、シェル・プロンプトをオープンします。
  2. シェル・プロンプトで rpm -ivh <RPM file> と入力します。 例えば、次のようにします。
    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 ファイルからのインストール

.tgz ファイルからインストールするための手順です。

  1. Java パッケージ・ファイルを保管するディレクトリーを作成します。本書の例は、/opt/ibm/java-i386-60/ にインストールされていることを前提としています。 この後で、/opt/ibm/java-i386-60/ を Java のインストール先ディレクトリーで置き換えてください。
  2. シェル・プロンプトで、tar -zxvf <.tgz file> と入力します。
    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) を表します。

  3. Security-Enhanced Linux (SELinux) を実行している場合は、システムに Java 共用ライブラリーを認識させる必要があります。 次のように入力します。
    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

JPackage 互換フォーマットの使用

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 を参照してください。

SDK and Runtime Environment for Linux の構成

Red Hat Advanced Server でのフォント・エンコードの不整合

注: (Linux IA 32 ビット中国語ユーザーのみ) Red Hat Advanced Server でのフォントのエンコードに不整合があるため、中国語をデフォルト言語とする環境にインストールを行う場合は、デフォルト言語を英語にしてインストールし、そのインストールが完了してから中国語に変更するようにしてください。そうしないと、中国語のフォントが表示されない可能性があります。

パスの設定

PATH 環境変数を変更すると、ご使用のパスにある既存の Java ランチャーがすべてオーバーライドされます。

PATH 環境変数により、Linux は、どの現行ディレクトリーからでも javac、java、および javadoc などのプログラムおよびユーティリティーを見つけられるようになります。ご使用の PATH の現行値を表示するには、コマンド・プロンプトで次のように入力します。

echo $PATH

ご使用のパスに Java ランチャーを追加するには、次のようにします。

  1. ホーム・ディレクトリーにあるシェル始動ファイル (ご使用のシェルによりますが、通常は、.bashrc) を編集し、 PATH 環境変数に絶対パスを追加してください。例えば、次のようにします。
    export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
  2. 再びログオンするか、または、更新したシェル・スクリプトを実行して、新しい PATH 環境変数をアクティブにします。

パスを設定した後は、任意のディレクトリーからコマンド・プロンプトでツールの名前を入力することにより、ツールを実行できます。例えば、ファイル Myfile.Java をコンパイルするには、コマンド・プロンプトで、以下のように入力します。

javac Myfile.Java

クラスパスの設定

クラスパスにより、SDK ツール (java、javac、および javadoc など) は Java クラス・ライブラリーがある場所がわかります。

以下に該当する場合のみ、クラスパスを明示的に設定する必要があります。

CLASSPATH 環境変数の現行値を表示するには、シェル・プロンプトで次のコマンドを入力します。

    echo $CLASSPATH

別にインストール済みの他のバージョンも含めて、 異なるランタイム環境を使用する複数のアプリケーションを作成し実行する場合、CLASSPATH および PATH をアプリケーションごとに明示的に設定する必要があります。複数アプリケーションを 同時に実行し、異なるランタイム環境を使用する場合、それぞれのアプリケーションが固有のシェル・プロンプトで実行される必要があります。

SDK and Runtime Environment for Linux のアンインストール

SDK and Runtime Environment for Linux を除去するためのプロセスは、実行したインストールのタイプによって異なります。

手順については、『Red Hat Package Manager (RPM) パッケージのアンインストール』または『Tape Archive (TAR) 圧縮パッケージのアンインストール』を参照してください。

Red Hat Package Manager (RPM) パッケージのアンインストール

Red Hat Package Manager (RPM) パッケージをアンインストールするための手順です。

インストール可能 RPM パッケージをインストールしてある場合、SDK or Runtime Environment for Linux をアンインストールするには、次のようにします。

  1. インストール済みの RPM パッケージを確認するために、rpm -qa |grep -i java と入力します。

    インストール済みのすべての 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 などのグラフィック・ツールを使用することもできます。

  2. PATH ステートメントから SDK and Runtime Environment のインストール先のディレクトリーを除去します。
  3. (Linux IA 32 ビットおよび PPC32 のみ) Java Plug-in をインストールしてある場合は、Web ブラウザー・ディレクトリーから Java Plug-in ファイルを除去します。

Tape Archive (TAR) 圧縮パッケージ のアンインストール

圧縮パッケージから抽出された IBM SDK for Linux, v6 を除去するためのステップのリストです。

  1. SDK または Runtime Environment のインストール先ディレクトリーから、Runtime Environment ファイルまたは Runtime Environment ファイルを除去します。
  2. PATH ステートメントから、SDK または Runtime Environment のインストール先ディレクトリーを除去します。
  3. 再びログオンするか、または、更新したシェル・スクリプトを実行して、新しい PATH 設定をアクティブにします。
  4. (Linux IA 32 ビットおよび AMD64/EM64T のみ) Java Plug-in をインストールしてある場合は、Web ブラウザー・ディレクトリーから Java Plug-in ファイルを除去します。

Java アプリケーションの実行

Java アプリケーションは、java ランチャーまたは JNI を使用して開始できます。設定値は、コマンド行引数、環境変数、およびプロパティー・ファイルを使用して Java アプリケーションに受け渡されます。

java および javaw コマンド

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 ... ]

パラメーター

[options]
ランタイム環境に渡されるコマンド行オプション。
<class>
始動クラス。クラスは main() メソッドを含む必要があります。
<file.jar>
呼び出す JAR ファイルの名前。-jar オプションでのみ使用されます。 指定された jar ファイルにはアプリケーションのクラスおよびリソース・ファイルが入っていて、始動クラスは Main-Class マニフェスト・ヘッダーで示される必要があります。
[arguments ...]
始動クラスの main() 関数に渡されるコマンド行引数。

バージョン情報の取得

ご使用の Java インストール済み環境の IBM ビルドおよびバージョン番号は、-version オプションを使用して取得します。|-Xjarversion オプションを使用すると、クラスパスにあるすべての jar ファイルのバージョン情報も取得できます。

  1. シェル・プロンプトを開きます。
  2. 以下のコマンドを入力します。
        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 オプションを指定するこれらのメソッドは、優先順位の順序でリストされます。

  1. コマンド行でオプションまたはプロパティーを指定します。 例えば、次のようにします。
    java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. オプションを含むファイルを作成し、-Xoptionsfile=<file> を使用してそれをコマンド行で指定します。
  3. オプションを含む IBM_JAVA_OPTIONS という環境変数を作成します。 例えば、次のようにします。
    export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"

コマンド行では、右端のオプションが左端のオプションより優先されます。 例えば、

java -Xint -Xjit myClass

というオプションを指定したとします。 この場合、-Xjit オプションが優先されます。

標準オプション

標準オプションの定義

-agentlib:<libname>[=<options>]
ネイティブ・エージェント・ライブラリー <libname> をロードします。例えば、-agentlib:hprof のようにします。詳しくは、コマンド行で -agentlib:jdwp=help-agentlib:hprof=help を指定してください。
-agentpath:libname[=<options>]
絶対パス名でネイティブ・エージェント・ライブラリーをロードします。
-cp <: で区切られたディレクトリーおよび zip または jar ファイル>
アプリケーション・クラスおよびリソースの検索パスを設定します。-classpath および -cp を使用せず、CLASSPATH 環境変数を設定しない場合、デフォルトでは、ユーザー・クラスパスは現行ディレクトリー (.) になります。
-classpath <: で区切られたディレクトリーおよび zip または jar ファイル>
アプリケーション・クラスおよびリソースの検索パスを設定します。-classpath および -cp を使用せず、CLASSPATH 環境変数を設定しない場合、デフォルトでは、ユーザー・クラスパスは現行ディレクトリー (.) になります。
-D<property name>=<value>
システム・プロパティーを設定します。
-help または -?
使用法メッセージを表示します。
-javaagent:<jarpath>[=<options>]
Java プログラミング言語エージェントをロードします。詳しくは、java.lang.instrument API の資料を参照してください。
-jre-restrict-search
バージョン検索でユーザーのプライベート JRE を含めます。
-no-jre-restrict-search
バージョン検索でユーザーのプライベート JRE を除外します。
-showversion
製品のバージョンを表示して継続します。
-verbose:<option>
詳細出力を使用可能にします。使用可能なオプションは以下のとおりです。
class
ロードされたクラスごとに、stderr に項目を書き込みます。
gc
詳細なガーベッジ・コレクション情報を stderr に書き込みます。出力を制御するには、 -Xverbosegclog を使用してください。詳しくは、「Diagnostics Guide (英語)」を参照してください。
jni
アプリケーションと JVM によって呼び出される JNI サービスを説明する情報を stderr に書き込みます。
sizes
アクティブなメモリー使用量設定について説明する情報を stderr に書き込みます。
stack
各スレッドの Java および C のスタック使用量について説明する情報を stderr に書き込みます。
-version
製品バージョンを印刷します。
-version:<value>
指定されたバージョンの実行を要求します。例えば「1.5」などです。
-X
非標準オプションのヘルプを表示します。

java コマンドのグローバリゼーション

java および javaw ランチャー では、現行ロケールの文字セット内の任意の文字を含む引数およびクラス名が受け入れられます。また、Java エスケープ・シーケンスを使用して、クラス名と引数に任意の Unicode 文字を指定することもできます。

これを行うには、-Xargencoding コマンド行オプションを使用します。

-Xargencoding
引数エンコード方式を使用します。Unicode 文字を指定するには、エスケープ・シーケンスを ¥u#### の形式で使用します。ここで # は 16 進数字 (0 から 9、A から F) です。
-Xargencoding:utf8
UTF8 エンコード方式を使用します。
-Xargencoding:latin
ISO8859_1 エンコード方式を使用します。

例えば、「HelloWorld」というクラスを 2 つの大文字について Unicode エンコード方式を使用して指定する場合、 次のコマンドを使用します。

java -Xargencoding '¥u0048ello¥u0057orld'

java および javaw コマンドは、翻訳されたメッセージを示します。これらのメッセージは、Java が稼働しているロケールに基づいて異なります。java が戻す、エラーの詳細説明やその他のデバッグ情報は、英語で表示されます。

Just-In-Time (JIT) コンパイラー

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 の使用不可化

JIT はいくつかの異なる方法で使用不可に設定できます。どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。

JIT をオフにすることは、Java アプリケーションをデバッグするときの問題の切り分けに役立つ、一時的な手段です。

JIT の使用可能化

デフォルトでは JIT は使用可能になっています。JIT は、以下のいくつかの異なる方法で明示的に使用可能にできます。どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。

JIT が使用可能かどうかを判別する

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
(デフォルトおよび推奨値。) 非常に高いスループットをアプリケーションに提供しますが、 代償として時折休止します。
-Xgcpolicy:optavgpause
ガーベッジ・コレクション休止に費やされる時間を削減し、 ヒープ・サイズの増加がガーベッジ・コレクション休止の長さに与える影響を制限します。非常に大規模なヒープが構成にある場合には、optavgpause を使用します。
-Xgcpolicy:gencon
並行と世代別の GC を組み合わせた使用を要求し、 ガーベッジ・コレクションの休止に費やされる時間を最小にするよう支援します。
-Xgcpolicy:subpool
(PPC および zSeries のみ。) 改良されたオブジェクト割り振りアルゴリズムを使用して、 ヒープでのオブジェクトの割り振り時にパフォーマンスを向上させます。このオプションは、大規模な SMP システムでパフォーマンスを向上させる可能性があります。

休止時間

アプリケーションがオブジェクトを作成しようとして、その要求がヒープ内の使用可能スペースの理由ですぐに実現しない場合に、ガーベッジ・コレクターは、参照されていないオブジェクト (ガーベッジ) を 識別してそれらを削除し、ヒープの状態を、即時および後続の割り振り要求にすぐに応じられる状態に 戻す必要があります。

そうしたガーベッジ・コレクションの繰り返しにより、アプリケーション・コードの実行時に 予期しない休止が時々起こることがあります。アプリケーションは大きく複雑になってきており、 ヒープもそれに応じて大規模になっているので、 このガーベッジ・コレクション休止時間は長さも重要度も増す傾向にあります。

デフォルトの ガーベッジ・コレクション値の -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 拡張パスに手動で追加する必要があります。これは、以下のいずれかの方法を使用して実現できます。

| |

|

SDK または Runtime Environment を別のディレクトリーにインストールした場合、SDK または Runtime Environment をインストールした |ディレクトリーで /opt/ibm/java-i386-60/ を置き換えてください。

SDK を使用した Java アプリケーションの開発

SDK for Linux には、Java ソフトウェア開発に必要な多数のツールおよびライブラリーが含まれています。

使用可能なツールの詳細については、SDK ツールおよび参照情報を参照してください。

| | |

XML の使用

|
|

IBM SDK には、XML4J パーサー、XL XP-J パーサー、XL TXE-J 1.0 XSLT コンパイラー、XSLT4J XSLT インタープリターが組み込まれています。 |これらのツールを使用すると、XML 処理の実装とは関係なく、XML 文書を解析、検証、変換、およびシリアライズできます。

|

|

ファクトリー・ファインダーを使用して抽象ファクトリー・クラスの実装を検出します (XML プロセッサーの選択を参照)。 |ファクトリー・ファインダーを使用することにより、Java コードを変更せずに、他の XML ライブラリーを選択できます。

|

| |

使用可能な XML ライブラリー

|

IBM SDK for Java には、以下の XML ライブラリーが含まれています。

|
|
XML4J 4.5
|
|

XML4J は、以下の規格をサポートしている検証パーサーです。 |

|
    |
  • XML 1.0 (第 4 版)
  • |
  • XML 1.0 (第 2 版) の名前空間
  • |
  • XML 1.1 (第 2 版)
  • |
  • XML 1.1 (第 2 版) の名前空間
  • |
  • W3C XML Schema 1.0 (第 2 版)
  • |
  • XInclude 1.0 (第 2 版)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Level 3 Core, Load and Save
  • |
  • DOM Level 2 Core, Events, Traversal and Range
  • |
  • JAXP 1.4
| |

XML4J 4.5 は Apache Xerces-J 2.9.0 に基づいています。詳しくは、http://xerces.apache.org/xerces2-j/ を参照してください。

|
|
XL XP-J 1.1
|
|

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 参照情報を参照してください。

|
|
XL TXE-J 1.0.1 Beta
|
|

バージョン 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 は、次の規格をサポートしています。 |

|
    |
  • XSLT 1.0
  • |
  • XPath 1.0
  • |
  • JAXP 1.4
|
|
|

| |

XML プロセッサーの選択

|

XML プロセッサーの選択は、 |サービス・プロバイダーを使用して実行されます。ファクトリー・ファインダーを使用している場合、Java は以下の場所で、使用するサービス・プロバイダーを検索します。 |

|
    |
  1. サービス・プロバイダーと同じ名前を持つシステム・プロパティー
  2. |
  3. XMLEventFactory、XMLInputFactory、XMLOutputFactory のみ: /opt/ibm/java-i386-60/jre/lib/stax.properties ファイル内のサービス・プロバイダーの値
  4. |
  5. その他のファクトリーの場合: /opt/ibm/java-i386-60/jre/lib/jaxp.properties ファイル内のサービス・プロバイダーの値
  6. |
  7. META-INF/services/<service.provider>ファイルの内容
  8. |
  9. デフォルトのサービス・プロバイダー
|

以下のサービス・プロバイダーは、Java が使用する XML 処理ライブラリーを制御します。 |

|
|
javax.xml.parsers.SAXParserFactory
|
SAX パーサーを選択します。デフォルトでは、XML4J ライブラリーの org.apache.xerces.jaxp.SAXParserFactoryImpl が使用されます。 |
|
javax.xml.parsers.DocumentBuilderFactory
|
文書ビルダーを選択します。デフォルトでは、XML4J ライブラリーの org.apache.xerces.jaxp.DocumentBuilderFactoryImpl が使用されます。 |
|
javax.xml.datatype.DatatypeFactory
|
データ型ファクトリーを選択します。デフォルトでは、XML4J ライブラリーの org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl が使用されます。 |
|
javax.xml.stream.XMLEventFactory
|
StAX イベント・ファクトリーを選択します。デフォルトでは、XL XP-J ライブラリーの com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl が使用されます。 |
|
javax.xml.stream.XMLInputFactory
|
StAX パーサーを選択します。デフォルトでは、XL XP-J ライブラリーの com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl が使用されます。 |
|
javax.xml.stream.XMLOutputFactory
|
StAX シリアライザーを選択します。デフォルトでは、XL XP-J ライブラリーの com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl が使用されます。 |
|
javax.xml.transform.TransformerFactory
|
XSLT プロセッサーを選択します。可能な値は以下のとおりです。 | |
|
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
|
XL TXE-J コンパイラーを使用します。これはデフォルトです。 |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
XSLT4J インタープリターを使用します。 |
|
|
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
W3C XML Schema 言語のスキーマ・ファクトリーを選択します。デフォルトでは、XML4J ライブラリーの org.apache.xerces.jaxp.validation.XMLSchemaFactory が使用されます。 |
|
javax.xml.xpath.XPathFactory
|
XPath プロセッサーを選択します。デフォルトでは、XSLT4J ライブラリーの org.apache.xpath.jaxp.XPathFactoryImpl が使用されます。 |
|

| |

XL-TXE-J のマイグレーション

|
|

デフォルト 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 コンパイラーにマイグレーションするには、次の手順で操作します。

|
    |
  1. javax.xml.transform.TransformerFactory サービス・プロバイダーを設定する場合、 com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl を使用します。
  2. |
  3. XSLT4J コンパイラーによって生成されたクラス・ファイルを再生成します。XL TXE-J では、XSLT4J コンパイラーによって生成されたクラス・ファイルを実行できません。
  4. |
  5. コンパイラーにより生成される一部のメソッドが、JVM メソッドのサイズ制限を超えることがあります。この場合、コンパイラーはサイズ制限を超過したメソッドを小さなメソッドに分割する操作を試行します。 | |
      |
    • コンパイラーによりメソッドが正常に分割されると、次の警告が表示されます:「一部の生成された関数が JVM メソッドのサイズ制限を超過し、自動的に小さい関数に分割されました。パフォーマンスを向上させるには、非常に大きいテンプレートを小さいテンプレートに分割したり、Process コマンドや Compile コマンドで 'splitlimit' オプションを使用したり、'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit' TransformerFactory 属性を設定します。」という警告が表示されます。コンパイル済みクラスを使用できますが、分割制限を手動で制御することによってパフォーマンスを向上させることができます。
    • |
    • コンパイラーがメソッドを分割できないと、「com.ibm.xtq.bcel.generic.ClassGenException: |Branch target offset too large for short」または「bytecode array size > 65535 at offset=#####」という例外が表示されます。分割制限を手動で設定するか、または分割制限を小さくしてください。
    分割制限を設定するには、Process コマンドまたは Compile コマンドを使用するときに -SPLITLIMIT オプションを使用するか、または transformer factory を使用するときに http://www.ibm.com/xmlns/prod/xltxe-j/split-limit transformerfactory 属性を使用します。分割制限は 100 から 2000 の間に設定できます。分割制限を手動で設定する場合、最善のパフォーマンスを得るには、設定可能な最大の分割制限を使用してください。
  6. |
  7. XL TXE-J は、XSLT4J コンパイラーよりも多くのメモリーを必要とします。メモリーが不足してきた場合、またはパフォーマンスが遅いように思える場合は、-Xmx オプションを使用してヒープ・サイズを大きくしてください。
  8. |
  9. 新規属性キーを使用するようにアプリケーションをマイグレーションします。古い TransformerFactory 属性キーは使用してはいけません。古い名前は受け入れられますが、警告が出されます。 | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    表 1. 属性キーの XSL4J コンパイラーから 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 新規コンパイラーでは廃止
  10. |
  11. オプション: 最高のパフォーマンスを実現するためには、再利用可能な XSLT 変換を再コンパイルしないようにしてください。 コンパイル済みの変換を再利用するためには、以下のいずれかの方法を使用します。 | |
      |
    • ランタイム時にスタイルシートが変更されない場合は、ビルド・プロセスの一部としてテンプレートをコンパイルし、コンパイル済みのクラスをクラスパス上に配置します。 |org.apache.xalan.xsltc.Compile コマンドを使用してスタイルシートをコンパイルし、http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath TransformerFactory 属性を true に設定して、クラスパスからクラスをロードするようにします。
    • |
    • アプリケーションを複数回実行するときに、同一のスタイルシートが使用される場合は、http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet TransformerFactory 属性を true に設定すると、コンパイル済みスタイルシートが自動的にディスクに保存されて、再利用可能になります。コンパイラーは、コンパイル済みスタイルシートが使用可能な場合はそれを使用し、使用可能でない場合や期限切れの場合は、新規にスタイルシートをコンパイルします。http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory TransformerFactory 属性を使用して、コンパイル済みスタイルシートを保管するために使用するディレクトリーを設定します。 |デフォルトでは、コンパイル済みスタイルシートは、スタイルシートと同じディレクトリーに保管されます。
    • |
    • アプリケーションが長期実行アプリケーションで、同一のスタイルシートを再利用する場合は、 TransformerFactory を使用してスタイルシートをコンパイルし、Templates オブジェクトを作成します。Templates オブジェクトを使用すると、スタイルシートを再コンパイルせずに Transformer オブジェクトを作成できます。 |Transformer オブジェクトも再利用は可能ですが、スレッド・セーフではありません。
| |

XML 参照情報

|
|

XL XP-J ライブラリーと XL TXE-J XML ライブラリーは、SDK バージョン 6 の新機能です。この参照情報では、これらのライブラリーでサポートされる機能について説明します。

| | |

XL XP-J 参照情報

|
|

XL XP-J 1.1 は 高性能非検証パーサーであり、XML 1.0 および XML 1.1 文書のプル解析とストリーミング・シリアライゼーションのための双方向 API である StAX 1.0 (JSR 173) をサポートしています。

|

| |

サポートされない機能
|

XL XP-J でサポートされない StAX のオプション機能を次に示します。 |

|

|

| |

XMLInputFactory 参照
|

javax.xml.stream.XMLInputFactory 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLInputFactoryJavadoc を参照してください。

| |||||||||||||||||||||||||||||||||||||||||||
表 2.
プロパティー名 サポートの有無
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 リーダーを作成できるようにします。

|

| |

XMLStreamReader 参照
|

javax.xml.stream.XMLStreamReader 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLStreamReader Javadoc を参照してください。

| |||||||||||||||||||
表 3.
プロパティー名 サポートの有無
javax.xml.stream.entities あり
javax.xml.stream.notations あり
|

XL XP-J では、javax.xml.stream.isInterning プロパティーもサポートされています。このプロパティーは、API 呼び出しから戻された XML 名と名前空間 URI がパーサーにより拘束されていたかどうかを示すブール値を戻します。

|

| |

XMLOutputFactory 参照
|

javax.xml.stream.XMLOutputFactory 実装でサポートされるプロパティーを次に示します。これらのプロパティーの説明については、XMLOutputFactory Javadoc を参照してください。

| |||||||||||||||
表 4.
プロパティー名 サポートの有無
javax.xml.stream.isRepairingNamespaces あり
|

| |

XMLStreamWriter 参照
|

javax.xml.stream.XMLStreamWriter 実装でサポートされているプロパティーを次に示します。これらのプロパティーの説明については、XMLStreamWriter Javadoc を参照してください。

| |||||||||||||||
表 5.
プロパティー名 サポートの有無
javax.xml.stream.isRepairingNamespaces あり
|

XMLStreamWriter オブジェクトのプロパティーは読み取り専用です。

| | |

XL TXE-J 参照情報

|
|

XL TXE-J は、XSLT4J 2.7.8 インタープリターと XSLT コンパイラーが組み込まれた XSLT ライブラリーです。

|

| |

機能の比較表

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
表 6. XSLT4J インタープリター、XSLT4J コンパイラー、XL TXE-J コンパイラーの機能の比較
機能 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 または Xalan の使用

|
|

旧バージョンの Xerces (2.0 より前) または Xalan (2.3 より前) を |endorsed ディレクトリーに入れて使用している場合、アプリケーションを起動したときに NullPointerException が発生する可能性があります。 |この例外は、これらの古いバージョンが jaxp.properties ファイルを正しく処理しないために起きます。

|

|

この状態を避けるために、以下の次善策のいずれかを使用してください。 | |

|

Java アプリケーションのデバッグ

Java プログラムをデバッグするには、Java Debugger (JDB) アプリケーション、あるいは SDK for Linux で提供される Java Platform Debugger Architecture (JPDA) を 使用して通信する他のデバッガーを使用できます。

Java を使用した問題診断について詳しくは、「Diagnostics Guide (英語)」を参照してください。

Java Debugger (JDB)

Java Debugger (JDB) は、SDK for Linux に組み込まれています。このデバッガーは、 jdb コマンドで呼び出されると、JPDA を使用して JVM に接続します。

Java アプリケーションをデバッグするには、以下のようにします。

  1. JVM を以下のオプションを付けて開始します。
    java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>
    JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。
  2. 別のセッションで、デバッガーを JVM に接続できます。
    jdb -attach <port>
    デバッガーが JVM に接続したら、一連のコマンドを実行して Java アプリケーションを 検査し制御することができます。例えば、run と入力して Java アプリケーションを 開始させることができます。

JDB オプションについて詳しく調べるには、次のように入力します。

jdb -help

JDB コマンドについて詳しく調べるには、次のようにします。

  1. jdb と入力します。
  2. JDB のプロンプトで、help と入力します。

また、JDB を使用して、リモート・マシンで実行中の Java アプリケーションもデバッグできます。 JPDA は、TCP/IP ソケットを使用してリモート JVM に接続します。

  1. JVM を以下のオプションを付けて開始します。
    java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>
    JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。
  2. デバッガーをリモート JVM に接続させます。
    jdb -attach <host>:<port>

Java Virtual Machine Debugging Interface (JVMDI) は、このリリースでサポートされていません。これは、Java Virtual Machine Tool Interface (JVMTI) に置き換えられています。

JDB と JPDA とその使用法について詳しくは、以下の Web サイトを参照してください。

アプリケーションが 32 ビットまたは 64 ビットのどちらの JVM で実行されているかを判別する

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 のシグナルの処理方法

JVM に関係のあるシグナルが生じると、シグナル・ハンドラーが呼び出されます。このシグナル・ハンドラーは、Java スレッドのために呼び出されたのか、または Java 以外のスレッドのために呼び出されたのかを判別します。

シグナルが Java スレッドのためのものである場合、JVM がシグナル処理の制御を行います。このシグナルの アプリケーション・ハンドラーがインストールされていて、 -Xnosigchain コマンド行オプションを指定しなかった場合、このシグナルのアプリケーション・ハンドラーは JVM の処理終了後に呼び出されます。

シグナルが Java 以外のスレッドのためのものであり、インストール済みのアプリケーションに、以前に JVM がそのシグナル用の独自のハンドラーをインストールしている場合、 制御はそのハンドラーに与えられます。そうでないと、シグナルが JVM または Java アプリケーションによって要求されても、シグナルは無視されるか、または、デフォルトのアクションがとられます。

例外およびエラーのシグナルの場合、JVM は以下のいずれかを行います。

上記のフックを指定するランチャーの作成に ついて詳しくは、 http://www.ibm.com/developerworks/java/library/i-signalhandling/ を参照してください。この項目は Java V1.3.1 を対象に書かれたものですが、それ以降のバージョンにも適用されます。

割り込みシグナルの場合にも JVM は制御されたシャットダウン・シーケンスに入りますが、この場合は、以下を行う正常終了として扱われます。

  1. そのシグナルのためのユーザー・アプリケーションのシグナル・ハンドラーを呼び出す。
  2. すべてのアプリケーション・シャットダウン・フックを実行する。
  3. アプリケーションがインストールした何らかの終了フックを呼び出す。
  4. 必要な JVM クリーンアップを実行する。

このシャットダウンは、Java メソッド System.exit() を呼び出すことによって開始されるシャットダウンと同一です。

JVM が使用するその他のシグナルは内部制御の目的のものであり、終了の原因となることはありません。関係のある 唯一の制御シグナルは SIGQUIT であり、これにより Javadump が生成されます。

JVM が使用するシグナル

シグナルのタイプには、例外、エラー、割り込みおよび制御があります。

下記の表 7 は、JVM が使用するシグナルを示したものです。 以下に、タイプまたは使用法ごとに表にグループ化したシグナルを示します。

例外
致命的な状態が発生すると、常にオペレーティング・システムが同期して該当する例外シグナルを生じさせるもの。
エラー
JVM がリカバリーできない状態を検出した場合で、JVM が SIGABRT を生じさせるもの。
割り込み
シャットダウンを要求するために、JVM プロセスの外部から割り込みシグナルを非同期に生じさせるもの。
制御
制御の目的で JVM が使用するその他のシグナル。

表 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 を使用するには、以下のようにします。

環境変数 JAVA_HOME は、SDK の場所 (例えば /opt/ibm/java-i386-60/) に設定してください。

libjsig.a を使用するには、以下のようにします。

JNI アプリケーションの作成

ネイティブ・プログラムが JNI_CreateJavaVM() API 呼び出しで指定できる有効な JNI バージョン番号は、JNI_VERSION_1_2(0x00010002) および JNI_VERSION_1_4(0x00010004) です。

制約事項: Java Native Interface (JNI) の Version 1.1 はサポートされません。

このバージョン番号で決まるのは、使用する 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 内に圧縮されています。

これらのクラスにより、ネットワーキング呼び出し、あるいは同期呼び出しでブロック化されたスレッドのブロックを解除できます。 これらのクラスを使用しない場合、アプリケーションは、 個別のブロックされたスレッドに割り込みをかけるのではなく、プロセス全体を終了させる必要があります。

これらのクラスは以下のとおりです。

public interface InterruptibleContext
2 つのメソッド isBlocked() および unblock() を定義します。 他の 3 つのクラスは InterruptibleContext を実装します。
public class InterruptibleLockContext
同期呼び出しに割り込みをするためのユーティリティー・クラス。
public class InterruptibleIOContext
ネットワーク呼び出しに割り込みをするためのユーティリティー・クラス。
public class InterruptibleThread
割り込み可能なメソッドのラッピングを許可するため、java.lang.Thread を拡張する ユーティリティー・クラス。 このクラスでは、InterruptibleLockContext および InterruptibleIOContext のインスタンスを使用し、同期操作とネットワーキング操作のどちらがスレッドをブロックしているかに応じて、必要な isBlocked メソッドおよび unblock() メソッドを実行します。

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 ビットを設定します。

CORBA サポート

Java Platform, Standard Edition (JSE) は、Sun の準拠資料に定義されている仕様は最小限サポートしています。場合によっては、IBM JSE ORB で、より新しいバージョンの仕様をサポートしている場合もあります。

サポートされる最小限の仕様は、『Official Specifications for CORBA support in Java SE 6』に定義されています。

GIOP 1.2 のサポート

この 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 の実行の通常フローをインターセプトすることができます。

Interoperable Naming Service のサポート

この 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 にも 移植できません。

ORB をトレースするためのシステム・プロパティー

ランタイム・デバッグ機能により、保守容易度が向上しました。これは、問題診断に有効であり、 IBM サービス担当員から要求される場合もあります。

プロパティーのトレース

com.ibm.CORBA.Debug=true
ORB トレースをオンにします。
com.ibm.CORBA.CommTrace=true
GIOP メッセージ (送信および受信) をトレースに追加します。
com.ibm.CORBA.Debug.Output=<file>
トレース出力ファイルを指定します。これはデフォルトでは orbtrc.DDMMYYYY.HHmm.SS.txt の形式です。

ORB トレースの例

例えば、イベントとフォーマット済み GIOP メッセージをコマンド行からトレースするには、以下のように入力します。

java -Dcom.ibm.CORBA.Debug=true
     -Dcom.ibm.CORBA.CommTrace=true <myapp>

制限

パフォーマンスの低下につながるので、通常の業務ではトレースをオンにしないようにしてください。 トレースをオフに切り替えても、FFDC (First Failure Data Capture) は作動していて、重大なエラーは報告されます。デバッグの出力ファイルが生成されたら、それを確認して問題について調べてください。例えば、 サーバーが ORB.shutdown() を実行せずに停止した可能性などがあげられます。

トレース出力の内容およびフォーマットは、バージョンによって異なります。

ORB を調整するためのシステム・プロパティー

ORB を調整して、特定のネットワークとうまく連動させることができます。ORB の調整に必要なプロパティーについて、以下で説明します。

com.ibm.CORBA.FragmentSize=<size in bytes>
GIOP 1.2 フラグメントの制御に使用されます。デフォルトのサイズは、1024 バイトです。

フラグメントを使用不可にするには、以下のようにフラグメント・サイズを 0 バイトにします。

java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
com.ibm.CORBA.RequestTimeout=<time in seconds>
CORBA 要求を待機する最大時間を設定します。デフォルトでは、ORB は無期限に待機します。接続の不必要な終了を避けるため、 タイムアウトに低すぎる値を設定しないでください。
com.ibm.CORBA.LocateRequestTimeout=<time in seconds>
CORBA LocateRequest を待機する最大時間を設定します。デフォルトでは、ORB は無期限に待機します。
com.ibm.CORBA.ListenerPort=<port number>
着信要求を読み取る ORB のポートを設定します。このプロパティーを設定すると、ORB は、初期化後すぐに listen を開始します。 それ以外の場合は、要求されたときにのみ listen を開始します。

ORB の Java セキュリティー権限

Java SecurityManager を使用して実行中に、CORBA API クラスのいくつかのメソッドを呼び出すと、 権限チェックが行われて、その結果 SecurityException になることがあります。 ご使用のプログラムが、これらのメソッドのいずれかを使用している場合は、必要な権限が付与されている ことを確認してください。

表 8. Java SecurityManager を使用して実行中に影響を受けるメソッド
クラス/インターフェース メソッド 必要な権限
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 実装クラスのリストです。

このリリースの ORB 実装クラスは以下のとおりです。

これらは、デフォルト値です。これらのプロパティーを設定しないか、または、 実装クラスを直接参照することをお勧めします。移植性を保つためには、実装ではなく、 CORBA API クラスのみを参照してください。これらの値は、今後のリリースで変更になる可能性があります。

RMI over IIOP

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 Handler Pool の実装

デフォルトでは、RMI Connection Handlers のスレッド・プーリングは使用可能になっていません。

RMI TCPTransport レベルで実装された接続プーリングを使用可能にするには、 以下のオプションを設定します。

-Dsun.rmi.transport.tcp.connectionPool=true

このバージョンの Runtime Environment には、接続プール内のスレッド数を制限するために使用可能な設定はありません。

拡張 BigDecimal

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.*; に変更してください。

Plug-in、アプレット・ビューアー、および Web Start

Java Plug-in は、ブラウザー内で Java アプリケーションを実行するために使用します。appletviewer は、ブラウザー内で実行するよう設計されているアプリケーションをテストするために使用します。Java Web Start は、ネットワーク上にデスクトップの Java アプリケーションをデプロイするために使用するものであり、それらのアプリケーションを常に最新の状態にする仕組みが備わっています。

(Linux IA 32 ビットおよび PPC32 のみ) Java Plug-in の使用

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 がサポートされています。

表 9. Linux IA32 で Java Plug-in によってサポートされるブラウザー
ブラウザー サポートされるバージョン
Mozilla 1.7.12, 1.8
Firefox 1.5, 2.0
表 10. Linux PPC32 で Java Plug-in によってサポートされるブラウザー
ブラウザー サポートされるバージョン
Mozilla 1.6
|SeaMonkey |1.0.8

ブラウザーのこれ以降のマイナー・リリースもサポートされています。

Java Plug-in のインストールおよび構成

Java Plug-in をインストールするには、ブラウザーのプラグイン・ディレクトリーへのシンボリック・リンクを作成します。

Java Plug-in は、Mozilla の Open JVM Integration イニシアチブが基本になっており、大半の Mozilla 製品および派生品 (Firefox など) と組み合わせて使用されます。

以下に、いくつかの一般的なブラウザーに Plug-in をインストールするための手順を示します。

JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。

Mozilla

Mozilla バージョン 1.4 以降のみがサポートされます。

  1. root としてログインします。
  2. Mozilla Plug-in のディレクトリーに移動します (一部の Linux ディストリビューションでは異なる場合があります)。
  3. プラグインへのシンボリック・リンクを作成します。
     ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so 
    ここで、<arch> は、システムのアーキテクチャーを表します。

JavaPlug-in が使用可能で有効になっていることを確認するには、Mozilla で「ヘルプ」 -> 「Plug-in について」を選択します。

JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。

制約事項: /usr/local/mozilla/plugins/ に置くことができる Java Plug-in 共用ライブラリーは 1 つ だけです。 Mozilla では、この共用ディレクトリー (またはその下位にあるサブディレクトリー) に存在するファイルをすべて Plug-in として読み込もうとしますが、2 つのバージョンの Java Plug-in が読み込まれた場合、結果を予測することはできません。

Firefox

以下の手順を実行すると、すべてのユーザーが Java Plug-in を使用できるようになります。

  1. root としてログインします。
  2. Firefox プラグインのディレクトリーに移動します (一部の Linux ディストリビューションでは異なる場合があります)。
    cd /usr/local/mozilla-firefox/plugins/
  3. プラグインへのシンボリック・リンクを作成します。
     ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .
    ここで、<arch> は、システムのアーキテクチャーを表します。

JVM を見つけられるようにするために、Plug-in はコピーするのではなく、それに対するシンボリック・リンクを作成してください。

共通 Document Object Model (DOM) サポート

特定のブラウザーによる制約のために、org.w3c.dom.html パッケージのすべての機能を実装できない場合があります。

次のエラーのいずれかがスローされます。

DBCS パラメーターの使用

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 で参照できます。

(Linux IA 32 ビット、PPC32、および PPC64 のみ) Web Start の使用

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 Start は、Web ページまたはコマンド行から実行できます。Web Start アプリケーションは、Java アプリケーション・キャッシュに保管されます。

Java Web Start バージョン 6 は、.rpm または .tgz パッケージによる Java のインストール時に、自動的にインストールされます。 Java を .tgz パッケージから解凍した場合、jre/lib/javaws/updateSettings.sh シェル・スクリプトを実行して、システムの .mailcap および .mime.types ファイルを更新してください。

Web Start は、以下のいくつかの異なる方法で起動できます。

(Linux IA 32 ビットのみ) WebStart Secure の静的バージョン管理

静的バージョン管理を使用すると、Web Start アプリケーションで稼働させる特定の JVM バージョンを要求できます。この機能を使用すると、アプリケーションは、新規 JVM にアップグレードされたシステムで古いセキュリティーのぜい弱性を利用することができるため、Secure Static Versioning (SSV) がデフォルトで使用されます。

SSV を使用する場合、特定の JVM の使用を要求する未署名 Web Start アプリケーションを実行しようとすると警告されます。署名付きアプリケーションと、JVM の最新バージョンを要求するアプリケーションは正常に稼働します。

SSV は、deployment.properties ファイルの deployment.javaws.ssv.enabled プロパティーを false に設定することによって使用不可にできます。

Java アプリケーションの出荷

Java アプリケーションは一般にクラス、リソース、およびデータ・ファイルで構成されています。

Java アプリケーションを出荷する場合、 ソフトウェア・パッケージは、多くの場合、以下のパーツから構成されます。

アプリケーションを実行するには、ユーザーに Runtime Environment for Linux が必要です。 SDK for Linux ソフトウェアには Runtime Environment が含まれます。ただし、 ユーザーが SDK for Linux ソフトウェアをインストール済みであることを前提にすることはできません。

SDK for Linux ソフトウェアのライセンスでは、 SDK のファイルをアプリケーションとともに再配布することが許可されません。 ライセンス交付を受けた SDK for Linux がターゲット・マシンにインストールされていることを確認してください。

JVM 間でのクラス・データの共用

クラス・データの共用によって、複数の 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」を付け加えてください。

-Xscmaxaot<size>
AOT データで使用できるキャッシュの最大バイト数を設定します。このオプションを使用すると、AOT 以外のデータでかなりの量のキャッシュ・スペースを使用できるようになります。デフォルトでは、AOT データの最大限度は、キャッシュのフリー・スペースの量となります。このオプションの値は、-Xscminaot の値以上、-Xscmx の値以下である必要があります。
-Xscminaot<size>
AOT データ用に予約できるキャッシュの最小バイト数を設定します。デフォルトでは、AOT データがキャッシュに書き込まれても、キャッシュがフルになるか -Xscmaxaot 制限に達するまで、AOT データ用のスペースは予約されません。このオプションの値は -Xscmx または -Xscmaxaot の値を超えてはなりません。 -Xscminaot の値は常に、合計キャッシュ・サイズよりもかなり小さい値でなければなりません。それは、AOT データを作成できるのが、キャッシュ済みクラスに対してのみであるためです。-Xscminaot の値が -Xscmx の値と等しい場合、クラス・データや AOT データは保管されません。これは、AOT データにはキャッシュのクラスが関連付けられていなければならないためです。
-Xscmx<size>
キャッシュ・サイズを指定します。 このオプションは、キャッシュが作成されていて同じ名前のキャッシュが存在しない場合にのみ適用されます。デフォルト・キャッシュ・サイズは、プラットフォームによって異なります。 使用されるサイズ値を知るには、コマンド行引数として -verbose:sizes を追加します。最小キャッシュ・サイズは 4 KB です。最大キャッシュ・サイズも、プラットフォームによって異なります。(キャッシュ・サイズの制限を参照)
-Xshareclasses:<suboption>[,<suboption>...]
クラス・データ共用を使用可能にします。多くのサブオプションを指定でき、その中に複数のキャッシュ・ユーティリティーが含まれます。 キャッシュ・ユーティリティーは、VM を始動せずに、指定されたキャッシュに必要な操作を実行します。 複数のサブオプションをコンマで区切って組み合わせられますが、 各キャッシュ・ユーティリティーは相互に排他的です。キャッシュ・ユーティリティーの実行中には、「Java 仮想マシンを作成できませんでした (Could not create the Javavirtual machine)」というメッセージが表示されると想定されます。キャッシュ・ユーティリティーは仮想マシンを作成しません。

一部のキャッシュ・ユーティリティーは、以前のバージョンの Java のキャッシュや、ビット幅が異なる JVM で作成されたキャッシュでも機能します。このようなキャッシュは「非互換」キャッシュと呼ばれます。

-Xshareclasses オプションで、以下のサブオプションを使用できます。

help
すべてのコマンド行サブオプションをリストします。
name=<name>
指定された名前のキャッシュに接続します。そのキャッシュが存在しない場合は、それを作成します。 また、キャッシュ・ユーティリティーによって変更される (例えば、破棄) キャッシュを示す場合にも使用されます。listAllCaches ユーティリティーを使用して、名前が指定されたキャッシュの中で現在使用可能なものを示します。名前が指定されていない場合、デフォルトの名前「sharedcc_%u」が使用されます。キャッシュ名の中の %u には、現在のユーザー名が挿入されます。 キャッシュ名に %g を指定すると、現在のグループ名を挿入できます。
|cacheDir=<directory>
|キャッシュ・データの読み取り元および書き込み先のディレクトリーを設定します。デフォルトでは、<directory> は /tmp/javasharedresources です。ユーザーは、<directory> に対する十分な権限が付与されている必要があります。デフォルトでは、JVM は指定されたディレクトリーに永続キャッシュ・ファイルを直接書き込みます。永続キャッシュ・ファイルは、ファイル・システムから安全に移動および削除できます。 非永続キャッシュは共用メモリーに格納されます。このキャッシュには、メモリーの位置を記述する制御ファイルがあります。制御ファイルは指定されている cacheDir の javasharedresources サブディレクトリーに格納されます。 |このディレクトリーの中の制御ファイルを手動で移動または削除しないでください。listAllCaches ユーティリティー、 |destroyAll ユーティリティー、および expire サブオプションは、特定の cacheDir の有効範囲内でのみ機能します。
|readonly
|既存のキャッシュが読み取り専用権限で開かれます。このサブオプションが指定されている場合、JVM は新規キャッシュを作成しません。キャッシュを読み取り専用で開くことで、JVM によるキャッシュの変更が阻止されます。また、JVM は他のユーザーやグループが作成したキャッシュに、書き込み権限なしで接続できます。デフォルトでは、このサブオプションは指定されていません。
|nonpersistent
|非永続キャッシュが使用されます。デフォルトでは、JVM はオペレーティング・システムの再始動後も維持されるディスクにキャッシュ・ファイルを作成します。nonpersistent サブオプションを指定すると、共用メモリーにキャッシュが作成されますが、オペレーティング・システムのシャットダウン時にこの共用メモリーは失われます。非永続キャッシュと永続キャッシュには同じ名前を指定できます。非永続キャッシュに対して destroy などのユーティリティーを実行するときには、常に nonpersistent サブオプションを使用してください。デフォルトでは、このサブオプションは指定されていません。
groupAccess
新しいキャッシュにオペレーティング・システムの許可を設定し、 キャッシュへのグループ・アクセスを可能にします。デフォルトは、ユーザー・アクセスのみです。
verbose
詳細出力が使用可能になります。詳細出力には、共用クラス・キャッシュの全体的な状況と、詳細なエラー・メッセージが記述されます。
|verboseAOT
|キャッシュ内でコンパイル済み AOT コードが検出されている、または保管されている場合に、詳細出力が使用可能になります。AOT コードはヒューリスティックに生成されます。小規模アプリケーションの場合、生成された AOT コードがまったくない場合もあります。AOT キャッシングを使用不可にするには、noaot サブオプションを使用します。
verboseIO
キャッシュ入出力アクティビティーに関する詳細出力が生成され、保管および検出されたクラスに関する情報がリストされます。クラス・ローダーには、固有 ID (ブートストラップ・ローダーは常に 0) が与えられ、出力には現在有効なクラス・ローダー階層が示されます。各クラス・ローダーは、 この階層において、それぞれの親にクラスを要求しないと、ロードすることができません。 失敗した要求が多く見られるのが通常です。この動きは、クラス・ローダー階層で予想されるものです。
verboseHelper
Java ヘルパー API の詳細出力を使用可能にします。この出力では、ClassLoader によるヘルパー API の使用方法が示されます。
silent
すべての共用クラス・メッセージ (エラー・メッセージを含む) をオフにします。
nonfatal
クラス・データ共用が失敗していても、JVM の開始を許可します。JVM の通常の動作では、 クラス・データ共用が失敗した場合、VM の開始は拒否されます。 「nonfatal」が選択されていて、共用クラス・キャッシュの初期化が失敗した場合、JVM は読み取り専用モードでキャッシュに接続しようとします。接続が失敗すると、JVM はクラス・データ共用を使用せずに開始します。
none
コマンド行の最後に追加して、クラス・データ共用を使用不可にできます。 このサブオプションにより、コマンド行の前のほうにあるクラス共用引数は無効になります。
modified=<modified context>
実行時にバイトコードを変更する可能性がある JVMTI エージェントがインストールされている場合に使用します。 このサブオプションを指定せず、バイトコード変更エージェントがインストールされている場合、 クラスを安全に共用するのに余分なパフォーマンス・コストがかかります。<modified context> は、ユーザーが選択した記述子で、「myModification1」などです。 このオプションでは、キャッシュを分割し、コンテキスト myModification1 を使用する JVM のみが同じクラスを共用できるように します。例えば、ある変更コンテキストで HelloWorld を実行し、その後、別の変更コンテキストでそれを再実行した場合、 キャッシュにすべてのクラスが 2 回保管されます。詳しくは、実行時バイトコード変更を参照してください。
|reset
|キャッシュが破棄され、JVM 開始時にキャッシュが再作成されます。コマンド行の最後に追加できます (-Xshareclasses:reset)。
destroy (ユーティリティー・オプション)
namecacheDir、および nonpersistent サブオプションで指定されるキャッシュを破棄します。キャッシュは、それを使用するすべての JVM がシャットダウン済みで、ユーザーに十分な許可がある場合にのみ、破棄可能です。
destroyAll (ユーティリティー・オプション)
指定された cacheDir および nonpersistent サブオプションを使用して、使用可能なすべてのキャッシュの破棄を試行します。 キャッシュは、それを使用するすべての JVM がシャットダウン済みで、ユーザーに十分な許可がある場合にのみ、破棄可能です。
expire=<time in minutes>
共用クラスをロードする前に指定された期間に使用されなかったすべてのキャッシュを破棄します。これは JVM を終了しないため、ユーティリティー・オプションではありません。
listAllCaches (ユーティリティー・オプション)
指定されたキャッシュ・ディレクトリー内のすべての互換キャッシュと非互換キャッシュをリストします。cacheDir が指定されていない場合は、デフォルト・ディレクトリーが使用されます。キャッシュごとに、Java バージョンや現在の使用状況などの要約情報が表示されます。
printStats (ユーティリティー・オプション)
namecacheDir、および nonpersistent サブオプションにより指定されるキャッシュの要約情報を表示します。表示される最も有用な情報は、 キャッシュがどのぐらいフルであるか、また、それにいくつのクラスが含まれるかです。 stale クラスとは、ファイル・システム上で更新され、そのためにキャッシュによって「stale」とマーク付けされたクラスです。 stale クラスはキャッシュから消去されず、再利用できます。 詳しくは、「Diagnostics Guide (英語)」を参照してください。
printAllStats (ユーティリティー・オプション)

namecacheDir、および nonpersistent サブオプションにより指定されるキャッシュの詳細情報を表示します。すべてのクラスは、ロード元の位置への参照とともに発生順にリストされます。 クラス・メソッドの AOT コードもリストされます。

Diagnostics Guide (英語)」を参照してください。

|mprotect=[ all || default | none ]
|デフォルトでは、キャッシュが含まれているメモリー・ページは、特定のページの更新中を除き常時保護されています。これにより、偶発的な破損または意図的な破損からキャッシュを保護できます。キャッシュ・ヘッダーは、パフォーマンス・コストが低いため、デフォルトでは保護されません。「all」を指定すると、ヘッダーを含むすべてのキャッシュ・ページが保護されます。「none」を指定すると、ページは保護されません。
|noBootclasspath
|ブートストラップ・クラス・ローダーによってロードされたクラスが共用クラス・キャッシュに格納されないようにします。SharedClassURLFilter API と組み合わせて使用すると、 キャッシュに入れるクラスを正確に制御できます。共用クラス・フィルタリングについて詳しくは、「Diagnostics Guide (英語)」を参照してください。
|cacheRetransformed
|JVMTI の RetransformClasses 機能を使用して変換されたクラスのキャッシュを使用可能にします。
|noaot
|AOT コードのキャッシュとロードを使用不可にします。

キャッシュの作成、読み込み、モニター、および削除

共用クラス・データ・キャッシュのライフ・サイクルの概要を説明します。キャッシュ管理ユーティリティーの例も示します。

クラス・データ共用を使用可能にするには、アプリケーション・コマンド行に -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 を実行するユーザーは同じグループ内になければなりません。共用クラス・キャッシュにアクセスするための許可は、オペレーティング・システムによって執行されます。キャッシュ名が指定されない場合、 同じシステム上の複数のユーザーがデフォルトで独自のキャッシュを作成するように、 デフォルト名にユーザー名が付加されます。

SharedClassPermission の使用

クラス・データ共用と併せて 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) の使用

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 のインストール

Java Communications API をインストールする前に、SDK または Runtime Environment がインストール済みであることを確認してください。

もともと RPM パッケージを使用して Java をインストールしている場合は、 Java Communications API を RPM ファイルからインストールしてください。Java Communications API を RPM パッケージからインストールするには、RPM ファイルからの Java Communications API のインストールを参照してください。

Java Communications API を圧縮ファイルからインストールするには、以下のようにします。

  1. Java Communications API 圧縮ファイル ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz を、SDK または Runtime Environment がインストールされているディレクトリーに格納します。デフォルト・ ディレクトリーにインストールした場合、これは /opt/ibm/java-i386-60/ になります。
  2. シェル・プロンプトから、圧縮ファイルが入っているディレクトリーにコンテンツを解凍します。
    tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz

    ここで、<arch> はアーキテクチャー (i386、x86_64、ppc、または ppc64) を表します。

  3. |javacomm ファイルを、ご使用の SDK 内の適切なディレクトリーにコピーします。 | |
      |
    1. lib/libLinuxSerialParallel.so を jre/bin/ ディレクトリーにコピーします。
    2. |
    3. jar/comm.jar を jre/lib/ext/ ディレクトリーにコピーします。
    4. |
    5. lib/javax.comm.properties を jre/lib/ ディレクトリーにコピーします。
    デフォルトでは、SDK は /opt/ibm/java-i386-60/ ディレクトリーにインストールされます。

RPM ファイルからの Java Communications API のインストール

Java Communications API をインストールする前に、SDK または Runtime Environment がインストール済みであることを確認してください。

もともと RPM パッケージを使用して Java をインストールしている場合は、 Java Communications API を RPM ファイルからインストールしてください。

  1. root でログオンしていること確認して、シェル・プロンプトをオープンします。
  2. rpm -ivh コマンドを使用して、Java Communications API RPM ファイルをインストールします。 例えば、次のようにします。
    rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpm
    Java Communications API は、/opt/ibm/java-i386-60/ ディレクトリー構造の内部にインストールされます。
  3. |javacomm ファイルを、ご使用の SDK 内の適切なディレクトリーにコピーします。 | |
      |
    1. lib/libLinuxSerialParallel.so を jre/bin/ ディレクトリーにコピーします。
    2. |
    3. jar/comm.jar を jre/lib/ext/ ディレクトリーにコピーします。
    4. |
    5. lib/javax.comm.properties を jre/lib/ ディレクトリーにコピーします。
    デフォルトでは、SDK は /opt/ibm/java-i386-60/ ディレクトリーにインストールされます。

Java Communications API ファイルの場所

デフォルトでは、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 ファイルでのデバイスの指定

ファイル 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 に 割り振られます。

IBM ThinkPad でのシリアル・ポートの使用可能化

多くの 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 を使用して印刷をするときは、プリンターで「用紙送り」、「継続」、または類似したボタンを押す必要があります。

Java Communications API のアンインストール

Java Communications API をアンインストールする場合に使用する手順は、インストール可能な Red Hat Package Manager (RPM) パッケージをインストールしているか、Tape Archive (TAR) 圧縮パッケージをインストールしているかによって異なります。

Red Hat Package Manager (RPM) パッケージのアンインストール

RPM パッケージを使用して、Java Communications API をアンインストールします。

  1. rpm ツールを使用して、パッケージをアンインストールします。 シェル・プロンプトで、次のコマンドを入力します。
    rpm -e ibm-javacomm-3.0-0.0
    あるいは、kpackage や yast2 などのグラフィック・ツールを使用することもできます。
  2. Java Communications API をインストールしたディレクトリーに、必要なその他のツールが含まれていない場合は、そのディレクトリーを PATH ステートメントから削除します。
  3. |javacomm ライブラリーを SDK ディレクトリーに |コピーした場合は、以下のファイルを SDK ディレクトリーから削除します。 | |
      |
    • jre/bin/libLinuxSerialParallel.so
    • |
    • jre/lib/ext/comm.jar
    • |
    • jre/lib/javax.comm.properties
    デフォルトでは、SDK は /opt/ibm/java-i386-60/ ディレクトリーにインストールされます。

Tape Archive (TAR) 圧縮パッケージのアンインストール

TAR 圧縮パッケージをインストールした場合に、Java Communications API をアンインストールするには、以下の手順を実行します。

以下のファイルを、インストールしたディレクトリーから削除します。

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 アプリケーション用の便利なキー・ストロークの説明を参照してください。

Swing での JComboBox コンポーネントのキーボードによる探索

カーソル・キーを使用して JComboBox コンポーネントのドロップダウン・リストを上下に探索する場合、実際に項目が選択されるまで JComboBox のボタンあるいは編集可能フィールドは変更されません。これは、このリリースで正しい動作で、キーボードによる探索動作とマウスによる探索動作の 一貫性が保たれるため、アクセス可能度や使用可能度が向上します。

Web Start のアクセシビリティー (Linux IA 32 ビット、PPC32、および PPC64 のみ)

Version 5.0 以降では、Java Web Start にはアクセス可能度と使用可能度において種々の改善がなされて、例えば、スクリーン・リーダーのサポートが充実し、キーボード・ナビゲーションも改善されています。

コマンド行のみで、Web Start 用に使用可能になっている Java アプリケーションを起動することができます。設定オプションを変更するには、ユーザーのホーム・ディレクトリーにある構成ファイル .java/.deployment/.deployment.properties を編集する必要があります。このファイルは、編集する前にバックアップをとってください。 Java アプリケーション・キャッシュ・ビューアーで指定できる設定がすべて、構成ファイルにあるわけではありません。

本書に関するご意見

本書に関するご意見は、以下の連絡手段のいずれかを使用してご連絡ください。なお、これらの連絡手段は、技術的な問い合わせに答えるためではなく、資料に対するご意見のみをお聞きするために設けてあることを、ご了承ください。

ご意見の送り先は次のとおりです。

ただし、IBM にメッセージを送る際には、フィードバック・データ (質問、意見、提案事項な ど) を含め、メッセージに組み込む情報はすべて公表を承諾されたものとみなされる こと、IBM ではこれらの情報をいかなる義務も負うことなく、無制限にコピー、利用、開示し、かつ他に対して配布できることをご承知おきください。さらに、IBM では、 これらの情報に含まれるすべての着想、概念、ノウハウ、または技術を、製品の開発、 製造、および販売など、あらゆる目的に利用できるものとします。

付録A. 非標準オプション

以下にリストする -X オプションは非標準であり、予告なしに変更されることがあります。

<size> パラメーターを取るオプションでは、その数値の後に、キロバイトを示す「k」または「K」、メガバイトを示す「m」または「M」、あるいはギガバイトを示す「g」または「G」を付け加えてください。

<percentage> パラメーターをとるオプションでは、0 から 1 までの数値を使用します。例えば、50% は 0.5 となります。

-Xargencoding
引数リストに Unicode エスケープ・シーケンスを入れることができます。 このオプションは、デフォルトでオフに設定されています。
-Xbootclasspath:<: で区切られたディレクトリーおよび ZIP ファイルまたは JAR ファイル>
ブートストラップ・クラスおよびリソースの検索パスを設定します。 デフォルトでは、内部の VM ディレクトリーおよび .jar ファイル内のブートストラップ・クラスおよびリソースを検索します。
-Xbootclasspath/a:<: で区切られたディレクトリーおよび ZIP ファイルまたは JAR ファイル>
指定されたディレクトリー、ZIP、または JAR ファイルをブートストラップ・クラス・パスの最後に追加します。 デフォルトでは、内部の VM ディレクトリーおよび .jar ファイル内のブートストラップ・クラスおよびリソースを検索します。
-Xbootclasspath/p:<: で区切られたディレクトリーおよび ZIP ファイルまたは JAR ファイル>
指定されたディレクトリー、ZIP、または JAR ファイルをブートストラップ・クラス・パスの前に付加します。 -Xbootclasspath: または -Xbootclasspath/p: オプションを使用して、標準 API のクラスをオーバーライドするアプリケーションを配置しないでください。 そのような配置は、Java Runtime Environment バイナリー・コードのライセンス違反になります。 デフォルトでは、内部の VM ディレクトリーおよび .jar ファイル内のブートストラップ・クラスおよびリソースを検索します。
|-Xcheck:classpath
|クラスパスでエラーが見つかった場合に、警告メッセージを表示します。例えば、ディレクトリーの欠落や JAR ファイルの欠落などです。
-Xcheck:gc[:<scan options>][:<verify options>][:<misc options>]
ガーベッジ・コレクションの追加検査を行います。デフォルトでは、検査が実行されません。詳しくは、 -Xcheck:gc:help の出力を参照してください。
-Xcheck:jni
JNI 機能の追加検査を行います。デフォルトでは、検査が実行されません。
|-Xcheck:memory[:<option>]
厳密な検査を実行して、JVM が失敗して終了する原因となった JVM 内のメモリー・リークを識別します。オプションを指定しないと、デフォルトで all が使用されます。詳しくは、-Xcheck:memory:help の出力か、「Diagnostics Guide (英語)」を参照してください。
-Xcheck:nabounds
JNI 機能の追加検査を行います。デフォルトでは、検査が実行されません。
-Xclassgc
ガーベッジ・コレクションごとにクラス・オブジェクトの収集を使用可能にします。-Xnoclassgc も参照してください。 デフォルトでは、このオプションは使用可能です。
-Xcodecache<size>
コンパイル済み Java メソッドのネイティブ・コードを保管するメモリー・ブロックの割り振り単位を設定します。稼働しているアプリケーションに適切な単位を選択できます。デフォルトでは、CPU アーキテクチャーとシステムの能力に従って内部的に選択されます。
-Xcompactexplicitgc
すべての System.gc() 呼び出しで圧縮を実行します。 -Xnocompactexplicitgc も参照してください。 デフォルトでは、圧縮は内部的に起動されたときにのみに行われます。
-Xcompactgc
すべてのガーベッジ・コレクションで圧縮を実行します。-Xnocompactgc も参照してください。 デフォルトでは、圧縮は内部的に起動されたときにのみに行われます。
-Xconcurrentbackground<number>
並行マークで mutator スレッドを支援するために接続された低優先度バックグラウンド・スレッドの数を指定します。 デフォルトは、1 です。
-Xconcurrentlevel<number>
割り振り「負担」率を指定します。これは、割り振られたヒープの量と、 マークされたヒープの量との比率を示します。デフォルトは、8 です。
-Xconmeter:<soa|loa|dynamic>
LOA (Large Object Area) と SOA (Small Object Area) のどちらの使用率を測定するか、およびそれによって並行マーク中にどちらの割り振りに負担がかかるかを判断します。選択された領域に割り振りの負担が適用されます。
-Xconmeter:dynamic が指定された場合、どちらの領域が最初に満杯になるかに基づいて、測定する領域をコレクターが動的に判断します。 デフォルトでは、このオプションは -Xconmeter:soa に設定されます。
-Xdbg:<options>
アプリケーションのリモート・デバッグをサポートするデバッグ・ライブラリーをロードします。 詳しくは、Java アプリケーションのデバッグを参照してください。 -Xrunjdwp を指定すると、同じサポートが提供されます。
-Xdebug
デバッガーを使用可能にして JVM を開始します。デフォルトでは、デバッガーは使用不可です。
-Xdisableexcessivegc
GC で過度の時間が費やされた場合の OutOfMemoryError のスローを使用不可にします。デフォルトでは、このオプションはオフです。
-Xdisableexplicitgc
System.gc() を呼び出す VM へのシグナルが効力を持ちません。 デフォルトでは、System.gc() の呼び出しが、ガーベッジ・コレクションを起動します。
-Xdisablestringconstantgc
ストリング拘束テーブルのストリングが収集されないようにします。デフォルトでは、このオプションは使用不可です。
-Xdisablejavadump
エラーおよびシグナルによる javadump 生成をオフにします。デフォルトでは、Javadump 生成は使用可能です。
-Xenableexcessivegc
GC で過度の時間が費やされた場合、このオプションは割り振り要求に対して NULL を戻します。 それにより、OutOfMemoryError のスローが発生します。 ヒープが最大に拡張され、使用可能時間の 95% を GC が使用している場合のみ、このアクションが発生します。 この振る舞いはデフォルトです。
-Xenableexplicitgc
System.gc() を呼び出す VM へのシグナル通知により、ガーベッジ・コレクションが起動されます。これはデフォルトです。
-Xenablestringconstantgc
ストリング拘束テーブルのストリングを収集できるようにします。 デフォルトでは、このオプションは使用可能です。
-Xfuture
厳密なクラス・ファイル・フォーマット検査をオンにします。 将来のリリースでより厳密な検査がデフォルトになるため、 新しいコードの開発時にこのフラグを使用します。 デフォルトでは、厳密なフォーマット検査は使用不可です。
-Xgcpolicy:<optthruput|optavgpause|gencon|subpool> (PPC および zSeries 上のサブプール)
ガーベッジ・コレクターの振る舞いを制御します。 詳しくは、ガーベッジ・コレクションのオプションを参照してください。
-Xgcthreads<number of threads>
ガーベッジ・コレクション中、並列操作に使用されるヘルパー・スレッドの数を設定します。 デフォルトでは、スレッドの数は、存在する物理 CPU の数から 1 を引いた数に設定され、最小が 1 になります。
-Xgcworkpackets<number>
グローバル・コレクターで使用可能な作業パケットの総数を指定します。 指定されないと、コレクターは、最大ヒープ・サイズに基づいてパケットの数を割り振ります。
-Xint
Just-In-Time (JIT) コンパイラーを使用不可にして、JVM でインタープリターのみを使用するようにします。 デフォルトでは、JIT コンパイラーは使用可能です。
-Xiss<size>
初期の Java スレッド・スタック・サイズを設定します。デフォルトで 2 KB です。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
|-Xjarversion
|バージョン情報の取得を参照してください。
-Xjit[:<suboption>,<suboption>...]
JIT を使用可能にします。サブオプションの詳細については、「Diagnostics Guide (英語)」を参照してください。-Xnojit も参照してください。デフォルトでは、JIT は使用可能です。
-Xlinenumbers
デバッグのために、スタック・トレース内の行番号を表示します。 -Xnolinenumbers も参照してください。 デフォルトでは、行番号はオンです。
-Xloa
ラージ・オブジェクト域 (LOA) を割り振ります。オブジェクトは、SOA でなく、この LOA に割り振られます。 デフォルトでは、LOA が使用可能でないサブプールを除いて、すべての GC ポリシーに LOA が使用可能です。 -Xnoloa も参照してください。
-Xloainitial<percentage>
<percentage> は、0 から 0.95 で、 ラージ・オブジェクト域 (LOA) に割り振られる古い世代の現行スペースの初期パーセンテージを指定します。デフォルトは 0.05、つまり 5% です。
-Xloamaximum<percentage>
<percentage> は、0 から 0.95 で、 ラージ・オブジェクト域 (LOA) に割り振られる古い世代の現行スペースの最大パーセンテージを指定します。デフォルトは 0.5、つまり 50% です。
-Xlp
大規模ページで Java ヒープを割り振るよう JVM に要求します。大規模ページが使用可能でない場合、JVM は始動せず、「GC: システム構成がオプションをサポートしません --> '-Xlp' (GC: system configuration does not support option --> '-Xlp')」というエラー・メッセージが表示されます。JVM は shmget() を使用して、ヒープに大規模ページを割り振ります。 大規模ページは、Linux カーネル v2.6 以上、 またはそれより前で大規模ページ・サポートがディストリビューションによってバックポートされているカーネルを稼働するシステムによってサポートされます。デフォルトでは、大規模ページは使用されません。大規模ページのメモリー割り振りの構成を参照してください。
-Xmaxe<size>
ガーベッジ・コレクターがヒープを拡張する差分の最大量を設定します。 通常、ガーベッジ・コレクターは、フリー・スペースの量が 30 % (または -Xminf で指定された量) を切ったときに、フリー・スペースを 30 % に戻すのに必要な量の分、ヒープを拡張します。 -Xmaxe オプションは、その拡張を指定値に制限します。 例えば、-Xmaxe10M では拡張が 10 MB に制限されます。デフォルトでは、最大の拡張サイズはありません。
-Xmaxf<percentage>
ガーベッジ・コレクション後にフリーである必要があるヒープの最大パーセンテージを指定します。 フリー・スペースがこの量を超えると、JVM がヒープの縮小を試行します。 デフォルト値は 0.6 (60 %) です。
-Xmca<size>
RAM 部分のロードされたクラスを保管するために割り振られるメモリーに対する、拡張の差分を設定します。 RAM 内のクラスの保管にさらにメモリーが必要になるたびに、 割り振りメモリーがこの量の分、増加されます。デフォルトでは、拡張の差分は 32 KB です。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmco<size>
ROM 部分のロードされたクラスを保管するために割り振られるメモリーに対する、拡張の差分を設定します。 ROM 内のクラスの保管にさらにメモリーが必要になるたびに、 割り振りメモリーがこの量の分、増加されます。デフォルトでは、拡張の差分は 128 KB です。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmine<size>
ガーベッジ・コレクターがヒープを拡張する差分の最小量を設定します。 通常、ガーベッジ・コレクターは、フリー・スペースを 30 % (または -Xminf で指定された量) に戻すのに必要な量の分、ヒープを拡張します。 -Xmine オプションは、拡張を少なくとも指定された値に設定します。 例えば、-Xmine50M では、拡張サイズが最小で 50 MB に設定されます。デフォルトでは、最小の拡張サイズは 1 MB です。
-Xminf<percentage>
ガーベッジ・コレクション後にフリーである必要があるヒープの最小パーセンテージを指定します。 フリー・スペースがこの量を切ると、JVM がヒープの拡張を試行します。 デフォルトでは、最小値は 0.3 (30%) です。
-Xmn<size>
-Xgcpolicy:gencon の使用時に、 新しい世代のヒープの初期および最大サイズを、指定された値に設定します。 -Xmn を設定する操作は、-Xmns および -Xmnx を設定する操作と同等です。-Xmns または -Xmnx を設定した場合、-Xmn は設定できません。-Xmns または -Xmnx とともに -Xmn を設定しようとすると、VM が始動せず、エラーが戻ります。 デフォルトでは、-Xmn はシステムの能力に従って内部的に選択されます。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmns<size>
-Xgcpolicy:gencon の使用時に、新しい世代のヒープの初期サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 このオプションを -Xmn と共に使用しようとすると、エラーが戻ります。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmnx<size>
-Xgcpolicy:gencon の使用時に、新しい世代のヒープの最大サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 このオプションを -Xmn と共に使用しようとすると、エラーが戻ります。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmo<size>
-Xgcpolicy:gencon の使用時に、 古い世代のヒープの初期および最大サイズを、指定された値に設定します。 -Xmos-Xmox の両方を設定することと同等です。 -Xmos または -Xmox を設定した場合、-Xmo は設定できません。-Xmos または -Xmox とともに -Xmo を設定しようとすると、VM が始動せず、エラーが戻ります。 デフォルトでは、-Xmo はシステムの能力に従って内部的に選択されます。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmoi<size>
-Xgcpolicy:gencon の使用時に、Java ヒープの増分量を設定します。 ゼロに設定されると、拡張はできません。 デフォルトでは、増分サイズは、拡張サイズ -Xmine および -Xminf を基に計算されます。
-Xmos<size>
-Xgcpolicy:gencon の使用時に、古い世代のヒープの初期サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 このオプションを -Xmo と共に使用しようとすると、エラーが戻ります。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmox<size>
-Xgcpolicy:gencon の使用時に、古い世代のヒープの最大サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 このオプションを -Xmo と共に使用しようとすると、エラーが戻ります。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmr<size>
-Xgcpolicy:gencon の使用時に、ガーベッジ・コレクションの「remembered set」のサイズを設定します。 これは、新しい世代のヒープ内のオブジェクトへの参照を持つ、 古い世代のヒープ内のオブジェクトのリストです。 デフォルトでは、このオプションは 16 K バイトに設定されます。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmrx<size>
記憶されている最大サイズ設定を設定します。
-Xms<size>
初期の Java ヒープ・サイズを設定します。 -Xmo も使用できます。デフォルトは、システムの能力に従って内部的に設定されます。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmso<size>
fork された Java スレッドの C スタック・サイズを設定します。デフォルトでは、このオプションは、32 ビット・プラットフォームでは 32 KB、 64 ビット・プラットフォームでは 256 KB に設定されます。-verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xmx<size>
最大 Java ヒープ・サイズを設定します。デフォルトでは、このオプションはシステムの能力に従って内部的に設定されます。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xnoclassgc
クラス・ガーベッジ・コレクションを使用不可にします。このオプションは、JVM で使用されていない Java クラスに関連するストレージのガーベッジ・コレクションをオフに切り替えます。-Xclassgc も参照してください。 デフォルトでは、クラス・ガーベッジ・コレクションが実行されます。
-Xnocompactexplicitgc
System.gc() の呼び出しで圧縮を使用不可にします。 -Xcompactexplicitgc も参照してください。 デフォルトでは、System.gc() の呼び出しで圧縮は使用可能です。
-Xnocompactgc
ガーベッジ・コレクターの圧縮を使用不可にします。 -Xcompactgc も参照してください。 デフォルトでは、圧縮は使用可能です。
-Xnojit
JIT コンパイラーを使用不可にします。-Xjit も参照してください。 デフォルトでは、JIT コンパイラーは使用可能です。
-Xnolinenumbers
デバッグの行番号を使用不可にします。 -Xlinenumbers も参照してください。 デフォルトでは、行番号はオンです。
-Xnoloa
ラージ・オブジェクト域 (LOA) の割り振りを抑制します。すべてのオブジェクトが SOA に割り振られます。 デフォルトでは、LOA が使用可能でないサブプールを除いて、すべての GC ポリシーに LOA が使用可能です。 -Xloa も参照してください。
-Xnopartialcompactgc
増分圧縮を使用不可にします。 -Xpartialcompactgc も参照してください。
-Xnosigcatch
JVM シグナル処理コードを使用不可にします。 -Xsigcatch も参照してください。 デフォルトでは、シグナル処理は使用可能です。
-Xnosigchain
シグナル・ハンドラーのチェーニングを使用不可にします。 -Xsigchain も参照してください。 デフォルトでは、シグナル・ハンドラーのチェーニングは使用可能です。
-Xoptionsfile=<file>
JVM オプションと定義が入ったファイルを指定します。デフォルトでは、オプション・ファイルは使用されません。
-Xoss<size>
スレッドの Java スタック・サイズおよび C スタック・サイズを設定します。このオプションは互換性のために用意されているもので、指定された値に-Xss-Xmso の両方を設定することに相当します。
-Xpartialcompactgc
部分圧縮を使用可能にします。 デフォルトでは、このオプションは設定されず、すべての圧縮が全体的です。 -Xnopartialcompactgc も参照してください。
-Xquickstart
JIT コンパイルおよび最適化を遅延することによって、起動時間を改善します。デフォルトでは、クイック・スタートが使用不可で、JIT コンパイルの遅延はありません。
-Xrdbginfo:<host>:<port>
オプションをリモート・デバッグ情報サーバーにロードして渡します。 デフォルトでは、リモート・デバッグ情報サーバーは使用不可です。
-Xrs
オペレーティング・システムのシグナルの使用を減らします。デフォルトでは、 VM はオペレーティング・システムのシグナルをすべて使用します。JVM が使用するシグナルを参照してください。
-Xrun<library name>[:<options>]
ヘルパー・ライブラリーをロードします。複数のライブラリーをロードするには、コマンド行で 2 回以上指定してください。これらのライブラリーの例は次のとおりです。
-Xrunhprof[:help] | [:<option>=<value>, ...]
ヒープ、CPU、またはモニターのプロファイル作成を実行します。詳しくは、「Diagnostics Guide (英語)」を参照してください。
-Xrunjdwp[:help] | [:<option>=< value>, ...]
アプリケーションのリモート・デバッグをサポートするデバッグ・ライブラリーをロードします。 詳しくは、『-Xdbg』を参照してください。
-Xrunjnichk[:help] | [:<option>=<value>, ...]
推奨されません。-Xcheck:jni を使用してください。
-Xscmx<size>
-Xscmx の詳細については、クラス・データ共用の使用可能化と構成を参照してください。
-Xshareclasses:<options>
-Xshareclasses オプションの詳細については、 クラス・データ共用の使用可能化と構成を参照してください。
-Xsigcatch
VM シグナル処理コードを使用可能にします。 -Xnosigcatch も参照してください。 デフォルトでは、シグナル処理は使用可能です。
-Xsigchain
シグナル・ハンドラーのチェーニングを使用可能にします。 -Xnosigchain も参照してください。 デフォルトでは、シグナル・ハンドラーのチェーニングは使用可能です。
-Xsoftrefthreshold<number>
対象がマークされていない場合に、ソフト参照がクリアされるまでの GC の回数を設定します。デフォルトは 3 です。これは、対象がマークされていない 3 番目の GC で、 ソフト参照がクリアされることを意味します。
-Xss<size>
スレッドの最大 Java スタック・サイズを設定します。 デフォルトでは、このオプションは 256 KB に設定されます。 -verbose:sizes オプションを使用して、VM が使用している値を出力します。
-Xthr:<options>
スレッド化オプションを設定します。
-Xverbosegclog:<path to file>[X,Y]

指定されたファイルに詳細ガーベッジ・コレクション (GC) 出力を書き出します。ファイルがすでに存在していると、上書きされます。それ以外の場合で、既存ファイルを開けないか、新しいファイルを作成できない場合は、出力は stderr にリダイレクトされます。引数 X および Y (両方とも整数) を指定すると、 詳細 GC 出力は X 個のファイルにリダイレクトされ、各ファイルには Y 個の gc サイクルの詳細 GC 出力が含まれます。これらのファイルは、filename1、filename2、... という形式になります。デフォルトでは、詳細 GC ロギングは行われません。

詳細 GC 出力について詳しくは、「Diagnostics Guide (英語)」を参照してください。

-Xverify
ロードされたすべてのクラスに対して厳密なクラス検査を使用可能にします。 デフォルトでは、厳密なクラス検査は使用不可です。
-Xverify:none
厳密なクラス検査を使用不可にします。 デフォルトでは、厳密なクラス検査は使用不可です。

付録B. 既知の制限

SDK および Runtime Environment for Linux の既知の制限。

問題の診断方法について詳しくは、「Diagnostics Guide (英語)」(http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html) を参照してください。

AMD64 SMP システムにおける BIOS 設定

ノード・メモリー・インターリービング (Node memory interleaving)」の BIOS 設定は「使用不可 (DISABLED)」に設定してください。 そうでないと、Java のクラッシュやハングを含む、予測不能な結果が発生する可能性があります。この指示は、AMD の推奨と一致しています。

JConsole モニター・ツールの「ローカル (Local)」タブ

IBM の JConsole ツールでは、同じシステム上の他の仮想マシンに接続できるようにするための「ローカル (Local)」タブを使用できません。 また、対応するコマンド行である pid オプションもサポートされていません。代わりに、JConsole の「リモート (Remote)」タブを使用して、モニター対象の仮想マシンに接続してください。あるいは、connection コマンド行オプションを使用して、ホスト localhost とポート番号を指定します。モニターするアプリケーションを起動するときに、次のコマンド行オプションを設定します。

-Dcom.sun.management.jmxremote.port=<value>
管理エージェントが listen するポートを指定します。
-Dcom.sun.management.jmxremote.authenticate=false
ユーザー名ファイルが作成されていない限り、認証を使用不可に設定します。
-Dcom.sun.management.jmxremote.ssl=false
SSL 暗号化を使用不可に設定します。

Rhino Javascript エンジンの使用不可

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 鍵ペアの作成は、低速なマシンでは非常に長い時間を要します。 十分な時間が経過すれば完了するので、遅れてもハングしたと解釈しないでください。DSA 鍵生成アルゴリズムは、標準の鍵の長さ (例えば、512、1024) を他より迅速に生成するよう、最適化されています。

JNI を使用した JVM の作成

ネイティブ・プログラムでは、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 のファイル記述子

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 ファイルは、すべて通常範囲で開かれます。

DBCS および KDE クリップボード

K Desktop Environment (KDE) を実行している場合は、Linux アプリケーションと Java アプリケーションの間で、システム・クリップボードを使用して 2 バイト文字セット (DBCS) の情報をコピーできない可能性があります。

LinuxThreads ライブラリーを使用するスレッドでの制限

SLES9および以降のディストリビューションでは、デフォルトのスレッド化ライブラリーが NPTL になっており、これにより Java スレッドがネイティブ・スレッドとしてインプリメントされます。それ以前のディストリビューションでは、デフォルトのスレッド化ライブラリーが LinuxThreads になっており、この場合はスレッドが新規プロセスとしてインプリメントされます。Java スレッドの数がプロセスの許容最大数を超えると、プログラムがハングする可能性があります。

使用可能なスレッドの最大数は、次の中の最低値によって決まります。

ただし、スレッドの最大数に達する前に、仮想ストレージを使い果たす可能性があります。

ThreadMXBean スレッド・ユーザーの CPU 時間制限

このプラットフォームでは、ユーザー・モードの CPU 時間とシステム・モードの CPU 時間を区別する方法はありません。ThreadMXBean.getThreadUserTime()、ThreadMXBean.getThreadCpuTime()、ThreadMXBean.getCurrentThreadUserTime()、および ThreadMXBean.getCurrentThreadCpuTime() はすべて、必要なスレッドの合計 CPU 時間を戻します。

KeyEvents とウィンドウ・マネージャー

Alt キーを含む KeyEvent の結果は、Linux のウィンドウ・マネージャーの種類によって異なる場合があります。 また、他のオペレーティング・システムの結果とも異なります。デフォルト設定を使用する場合、KWin ウィンドウ・マネージャーでは Ctrl+Alt+A によって KeyEvent が生成されるのに対し、Metacity ウィンドウ・マネージャーでは Ctrl+Alt+A はキー・イベントを生成しません。

X Window System と Meta キー

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 を使用して JVM を作成する場合の SIGSEGV

JNI アプリケーションからの JNI_CreateJavaVM() の呼び出しが原因で、セグメンテーション障害 (シグナル SIGSEGV) が起きる場合があります。この障害を回避するために、 オプション -lpthread を指定して JNI プログラムを再ビルドしてください。

高スレッド化アプリケーションでのリソースの不足

並行スレッドを数多く実行していると、次の警告メッセージが表示される場合があります。

java.lang.OutOfMemoryError

これは、マシンのシステム・リソースが不足していることを示します。メッセージは、次の理由によって生成される可能性があります。

対応するシステム・リソースが増加するように、システムの調整を試みてください。

X サーバーと X クライアントのフォント問題

Linux マシンで Java AWT または Swing アプリケーションを実行し、別のマシンに表示をエクスポートするときに、X クライアント・マシンにロードされているフォント・セットと X サーバー・マシンにロードされているフォント・セットが異なっていると、ダイアログを表示するときに問題が発生します。この問題を回避するには、両方のマシンに同じフォントをインストールします。

UTF-8 エンコード方式と MalformedInputExceptions

ご使用のシステム・ロケールで UTF-8 エンコード方式を使用している場合は、一部の SDK ツールによって sun.io.MalformedInputException がスローされる可能性があります。 システムで UTF-8 エンコード方式が使用されているかどうかを確認するには、LANGLC_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 問題

クロスプラットフォーム環境で AMI と xcin を使用する場合 (例えば、32 ビットと 64 ビットのシステムの間や、ビッグ・エンディアンとリトル・エンディアンのシステムの間で表示をエクスポートする場合) は、問題が発生する場合があります。この種の問題が発生した場合は、AMI と xcin の最新バージョンにアップグレードしてください。

RHEL4 と XIM

中国語、韓国語、および日本語の RHEL4 ユーザーの場合のみ

デフォルトでは XIM サーバーがインストールされません。DBCS 文字を Java アプリケーションに入力するには、iiimf-x や kinput2 などの XIM サーバー・パッケージをインストールしてください。

RHEL4 と IIIMF

中国語、韓国語、および日本語の 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 ユーザーの場合のみ

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

RHEL4 で xcin がハングする場合があります。この問題を解決するには、/etc/chinese/xcin/xcinrc ファイルで ICCHECK_DISABLE を「はい」に設定します。

64 ビット環境のみ

xcin (中国語 (繁体字) XIM サーバー) を使用する RHEL4 では、64 ビット環境 (AMD64 や zSeries 64 ビット・プラットフォームなど) で動作する Java でのセグメンテーション障害など、予期しない振る舞いが生じる場合があります。この問題を解決するには、最新の xcin パッケージにアップグレードしてください。

RHEL4 と IIIMF のフォーカス変更問題

RHEL4 のみ

IIMF (Internet Intranet Input Method Framework) を使用して DBCS 文字を入力するときに、フォーカス変更問題が生じる可能性があります。この問題は、アクティブな入力コンポーネントを最小化するときに発生します。 コンポーネントを復元すると、入力方式が SBCS に切り替わります。 DBCS は、その後手動でもう一度アクティブ化する必要があります。

次のコンポーネントの場合に、このフォーカス変更問題が発生します。

XIM と Java Plug-in

RHEL4、および SLES9 のみ

日本語、中国語、および韓国語のユーザーの場合は、Web ブラウザーの Java アプレットのテキスト・コンポーネントに、XIM を使用して各言語の文字を入力することができません。この制限は、XEmbed が X11 ライブラリー・ファイルへの修正を必要とすることに起因します。この状況を回避するには、-Dsun.awt.noxembed=true システム・パラメーターを指定して XEmbed を無効にします。このオプションは、コントロール・パネルを使用して設定できます。

  1. Java Plug-in コントロール・パネルを開き、「Java」タブに移動します。
  2. 「Java アプレットのランタイム設定」で、「表示」ボタンをクリックします。
  3. 「Java Runtime パラメーター」に -Dsun.awt.noxembed=true と入力し、「OK」をクリックします。
  4. 「適用」をクリックします。
  5. ブラウザーを起動します。

この制限は、RHEL4 U3 および SLES9 SP3 では解決されています。

アラビア文字と Matrox ビデオ・カード

Intel 32 ビット・プラットフォームのみ

アラビア語テキストのユーザーが、Matrox ビデオ・カードが搭載された、アクセラレーションが有効な Linux を使用すると、drawString を使用して大きなフォントを表示するときに文字がゆがむ可能性があります。この問題は、それらのカードのドライバーに起因します。回避策としては、デバイスのアクセラレーション機能を無効にすることを提案します。

SLES9 NPTL とパラレル・ポート・ドライバー

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 プラットフォームでのパラメーターが 8 個を超える JNI 呼び出し

PPC プラットフォームのみ

Java コードで JNI 呼び出しが使用されていて、いずれかの呼び出しに浮動小数点または倍精度パラメーターが 8 個より多くある場合は、C コードを GNU C Compiler (GCC) の gcc-2.95.3 Free Software Foundation (FSF) レベルでコンパイルする必要があります。

SP2 より前の SLES9 でのパラレル・ポート・オペレーション

PPC プラットフォームのみ

JavaComm パッケージでは、SLES 9 GA および SP1 カーネルでのパラレル・ポート・オペレーションをサポートできません。この制限は、SP2 カーネルでは解決されています。SUSE Bugzilla 番号は 50028 です。

PPC 64 ビット・プラットフォームでの libFileStat.so のコンパイル

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 プラットフォームでの IPv6

zSeries プラットフォームのみ

現行ディストリビューションの Linux カーネルは Internet Protocol バージョン 6 (IPv6) をサポートしますが、IPv6 を使用すると問題が発生する場合があります。Java による IPv6 のサポートはこのリリースに組み込まれていますが、java コマンドで -Djava.net.preferIPv4Stack=true オプションを指定し、このサポートをオフにすることをお勧めします。IPv6 に完全対応したカーネルをインストールする場合は、このオプションは不要です。

64 ビット zSeries プラットフォームでの xcin

zSeries 64 ビット・プラットフォームのみ

中国語および台湾語の入力方式サーバー (xcin) はテストされていません。

Java Desktop API

1 つ以上の GNOME ライブラリーが使用できないため、Java Desktop API が機能しない場合があります。

GTK Look and Feel と NullPointerException

DBCS 環境のみ

ご使用のアプリケーションで GTK Look and Feel を使用していて NullPointerException の障害が発生する場合、GNOME_DESKTOP_SESSION_ID 環境変数を設定解除してください。

Unicode Shift_JIS コード・ページ別名

日本語ユーザーのみ

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 の米国およびその他の国における商標です。

他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。