# IBM SDK and Runtime Environment for Linux platforms, Java 2 Technology Edition, Version 5.0

# ユーザー・ガイド

# 著作権情報

注: 本書および本書で紹介する製品をご使用になる前に、『特記事項』に記載されている情報をお読みください。

本書は、以下、および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

- IBM 32-bit SDK and Runtime Environment for Linux on Intel architecture, Java 2 Technology Edition Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on AMD64/EM64T architecture, Java 2 Technology Edition Version 5.0
- IBM 32-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition Version 5.0
- IBM 31-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition Version 5.0

(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.

(c) Copyright International Business Machines Corporation, 1999, 2005. All rights reserved.

(c) Copyright IBM Japan 2005

# 前書き

本書には、IBM(R) SDK and Runtime Environment for Linux(TM) platforms, Java(TM) 2 Technology Edition, Version 5.0 の概説と、 Sun の実装と対比した IBM の実装の相違点に関する具体的な情報が記載されています。 本書は、Sun の Web サイト (http://java.sun.com) の詳細な資料と一緒にお読みください。

SDK and Runtime Environment for Linux をテスト済みのディストリビューションのリストについては、http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html を参照してください。

IBM Virtual Machine for Java について詳しくは、 「Diagnostics Guide (英語)」を参照してください。

用語「Runtime Environment」と「Java 仮想マシン」は、本書を通じて読み替えることができます。

本書の Version 5.0 での技術的な変更は、小さな変更や明らかな変更 (「1.4.2」を「5.0」に書き換えた、など) を除き、 HTML やカラー印刷コピーでは赤で示され、また、変更個所の左側に縦線が示されています。

# 目次

著作権情報
前書き
概要
規則
バージョンの互換性
SDK のアップグレード
他の IBM JVM からのマイグレーション
| |
zSeries に対してサポートされるハードウェア
SDK および Runtime Environment のコンテンツ
Runtime Environment ツール
SDK ツール
SDK および Runtime Environment のインストールと構成
Red Hat Enterprise Linux (RHEL) 4 でのインストール
| |
64 ビット・アーキテクチャーでの 32-bit SDK のインストール
RPM ファイルからのインストール
.tgz ファイルからのインストール
SDK and Runtime Environment for Linux の構成
PATH の設定
CLASSPATH の設定
SDK and Runtime Environment for Linux のアンインストール
インストール可能 Red Hat Package Manager (RPM) パッケージのアンインストール
圧縮された Tape Archive (TAR) パッケージのアンインストール
Runtime Environment の使用
オプション
Java オプションおよびシステム・プロパティーの指定
標準オプション
非標準オプション
IBM ビルド番号およびバージョン番号の取得
java コマンドのグローバリゼーション
Just-In-Time (JIT) コンパイラー
JIT の使用不可化
JIT の使用可能化
JIT が使用可能かどうかを判別する
ガーベッジ・コレクション・ポリシーの指定
ガーベッジ・コレクションのオプション
休止時間
休止時間の削減
ヒープが満杯の環境
JVM によるシグナルの処理方法
JVM が使用するシグナル
ネイティブ・コード・ドライバーをシグナル・チェーニング・ライブラリーにリンクする
浮動スタックの処理
XML 文書の変換
旧バージョンの Xerces または Xalan の使用
SDK を使用した Java アプリケーションの開発
Java アプリケーションのデバッグ
Java Debugger (JDB)
アプリケーションが 32 ビットまたは 64 ビットのどちらの JVM で実行されているかを判別する
JNI アプリケーションの作成
| |
ブロックされたコネクターのスレッド・レベル・リカバリーのサポート
アプレットの処理
アプレット・ビューアーでアプレットを実行する
アプレット・ビューアーでアプレットをデバッグする
| |
大規模ページのメモリー割り振りの構成
CORBA サポート
GIOP 1.2 のサポート
ポータブル・インターセプターのサポート
Interoperable Naming Service のサポート
ORB をトレースするためのシステム・プロパティー
ORB を調整するためのシステム・プロパティー
ORB の Java 2 セキュリティー権限
ORB 実装クラス
RMI over IIOP
RMI の Connection Handler Pool の実装
拡張双方向言語サポート
拡張 BigDecimal
ユーロ記号のサポート
Java Communications API (JavaComm) の使用
Java Communications API のインストール
Java Communications API ファイルの位置
Java Communications API の構成
シリアルおよびパラレル・ポートのアクセス・モードを変更する
IBM ThinkPad でのシリアル・ポートの使用可能化
Java Communications API での印刷に関する制限
Java Communications API のアンインストール
Red Hat Package Manager (RPM) パッケージのアンインストール
圧縮された Tape Archive (TAR) パッケージのアンインストール
Java Communications API ドキュメンテーション
Java アプリケーションの配置
(Linux IA 32 ビットおよび PPC32 のみ) Java Plug-in の使用
サポートされるブラウザー
Java Plug-in のインストールと構成
共通 Document Object Model (DOM) サポート
DBCS パラメーターの使用
(Linux IA 32 ビット、PPC32、および PPC64 のみWeb Start の使用
Web Start の実行
Java アプリケーションの出荷
| |
JVM 間でのクラス・データの共用
| |
クラス共用の概要
| |
キャッシュの内容
| |
キャッシュの動的更新
| |
クラス共用の使用可能化
| |
キャッシュ・セキュリティー
| |
キャッシュの存続期間
| |
キャッシュ・ユーティリティー
| |
クラス共用のためのコマンド行オプションの使用
| |
キャッシュの作成、データ取り込み、モニター、および削除
| |
パフォーマンスとメモリー使用量
| |
クラス共用の使用の制限と考慮事項
| |
キャッシュ・サイズの制限
| |
実行時バイトコード変更
| |
オペレーティング・システムの制限
| |
SharedClassPermission の使用
| |
カスタム・クラス・ローダーの共用クラスへの適応
独立ソフトウェア販売会社のサービスおよびサポート
アクセシビリティ
iKeyman のアクセシビリティ
Swing での JComboBox コンポーネントのキーボードによる探索
(Linux IA 32 ビット、PPC32、および PPC64 のみ) Web Start のアクセシビリティ
既知の制限
特に指示がない限りすべての Linux プラットフォームに適用される制限
Linux IA 32 ビットに関する制限
Linux AMD64 の制限
Linux PPC 32 ビットおよび 64 ビットに関する制限
Linux PPC 64 ビットに関する制限
Linux zSeries 64 ビットに関する制限
Linux zSeries 31 ビットおよび 64 ビットに関する制限
本書に関するご意見
特記事項
商標

# 概要

IBM SDK は、IBM Java 5.0 Core Application Program Interface (API) に準拠した アプレットやアプリケーションを作成して実行するための開発環境です。

SDK には、Java アプリケーションの実行のみを可能にする、Runtime Environment for Linux が 含まれています。 SDK をインストールしている場合には、Runtime Environment が組み込まれています。

Runtime Environment には、Java 仮想マシンと、 デバッグ不可能な .so files とクラス・ファイルなどのサポート・ファイルが含まれています。 Runtime Environment には、SDK にあるクラスのサブセットのみが含まれていて、これは Java プログラムを実行時にサポートしますが、Java プログラムのコンパイルを 可能にするものではありません。 Runtime Environment for Linux には、 appletviewer あるいは Java コンパイラー (javac) などの開発ツールや、 開発システム専用のクラスは一切含まれていません。

さらに、IA32、PPC32、および 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/java2-i386-50/ として参照されます。 以下にリストしたプラットフォームでは、デフォルト・インストール・ディレクトリーが異なります。 /opt/ibm/java2-i386-50/ が出てきた場合には、ディレクトリーをご使用のプラットフォーム用に置き換えてください。

- Linux IA 32 ビット: /opt/ibm/java2-i386-50/
- Linux AMD 64 ビット: /opt/ibm/java2-x86_64-50/
- Linux PPC 32 ビット: /opt/ibm/java2-ppc-50/
- Linux PPC 64 ビット: /opt/ibm/java2-ppc64-50/
- Linux zSeries 31 ビット: /opt/ibm/java2-s390-50/
- Linux zSeries 64 ビット: /opt/ibm/java2-s390x-50/

## バージョンの互換性

以前のバージョンの SDK で稼働したアプレットあるいはアプリケーションは、 一般に、IBM SDK for Linux, v5.0 でも正しく動作します。 このリリースでコンパイルしたクラスの、前のリリースでの動作については保証できません。

互換性に関して Sun のドキュメンテーションを読む場合は、Sun の Web サイト http://java.sun.com を参照してください。

## SDK のアップグレード

前のリリースから SDK をアップグレードする場合は、アップグレードを進める前に、 すべての構成ファイルおよびセキュリティー・ポリシー・ファイルをバックアップしてください。

これらのファイルはアップグレード処理中に上書きされた可能性があるため、 アップグレードの後に、それらのリストアまたは再構成が必要な場合があります。 ファイルのフォーマットやオプションが変わった可能性があるため、 元のファイルをリストアする前に、新しいファイルの構文を確認してください。

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

Version 1.4.2 (AMD64/EM64T 用) と Version 5 (他の Linux プラットフォーム用) では、IBM Runtime Environment for Linux に、新しいバージョンの IBM Java Virtual Machine と Just-In-Time (JIT) コンパイラーが含まれています。以前の IBM Runtime Environment からマイグレーションする場合は、以下のことに注意してください。

- JVM 共用ライブラリー、libjvm.so は、ディレクトリー jre/bin/j9vm にインストールされます。 これは、 例えば、jre/bin/classic にインストールされる、Runtime Environment for Linux の Version 1.4.2 (AMD64/EM64T 以外のすべてのプラットフォーム用) とは異なります。JNI 呼び出しインターフェースを 使用するネイティブ・アプリケーションでは、JVM のダイナミック・リンク・ライブラリーを見つけるために、 その環境変数に新しいディレクトリー・パスを追加する必要があります。
- |JVM Monitoring Interface (JVMMI) は、使用できなくなりました。 |この API を使用するアプリケーションは書き直しの必要があります。 代わりに、 |JVM Tool Interface (JVMTI) を使うことをお勧めします。 JVMTI は、機能的には JVMMI と同等ではありません。 JVMTI に関して詳しくは、http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ および「Diagnostics Guide (英語)」を参照してください。
- |JNI の新規実装は、JNI 仕様に準拠しますが、 |以前の実装とは異なります。 オブジェクトを pin (固定) するのではなく、 |オブジェクトのコピーを戻します。 この違いにより、JNI アプリケーション・コードでエラーが発生する可能性があります。 JNI コードのデバッグについて詳しくは、『非標準オプション』の |-Xcheck:jni を参照してください。
- |-verbose:gc を使用して得られる、ガーベッジ・コレクター |詳細ログのフォーマットおよびコンテンツが変更されています。 現在、データは、XML 形式です。 データ内容には、JVM でのガーベッジ・コレクションの実装に対する変更が反映され、 |出力される統計のほとんどが変更されています。 |詳細 GC 出力を処理するプログラムがある場合、新規フォーマットとデータで動作するように変更する必要があります。 新しい詳細 GC データ例は、「Diagnostics Guide (英語)」を参照してください。
- IBM JRE の以前のバージョンは、jre/lib ディレクトリーにある rt.jar というファイルを同梱して出荷されていました。 Java v1.4 以降、このファイルは、jre/lib ディレクトリーにある複数の JAR ファイルに置き換えられています。
- |業界互換性と推奨されない API の追加情報については、 |Sun の Java 5 Compatibility のドキュメンテーションと Sun の Java 5 Depreciated API のリストを参照してください。

| | |

## zSeries に対してサポートされるハードウェア

|

zSeries 31-bit |および 64-bit SDK と Runtime Environment は、 |以下の System z9 および zSeries サーバーまたはそれと同等のもので稼働します。 |

|

|
- z9-109
|
- z990
|
- z900
|
- z890
|
- z800

# SDK および Runtime Environment のコンテンツ

SDK には、いくつかの開発ツールと Java Runtime Environment (JRE) が含まれています。 この節では、SDK ツールと Runtime Environment のコンテンツについて説明します。

全体が Java で書かれたアプリケーションでは、IBM SDK のディレクトリー構造 (あるいは、それらの ディレクトリー内のファイル) に対する依存関係が皆無であるべきです。 SDK のディレクトリー構造 (あるいは、それらのディレクトリー内のファイル) に対する依存関係があると、 アプリケーションの移植性の問題が生じる可能性があります。

## Runtime Environment ツール

- コア・クラス -- これは、プラットフォーム用にコンパイルされたクラス・ファイルで、 コンパイラーとインタープリターがアクセスできるように zip された状態のままである必要があります。 このクラスは変更しないで、サブクラスを作成して必要なところをオーバーライドするようにしてください。
- JRE ツール -- 以下のツールは、Runtime Environment の一部で、 特に指定されない限り、jre/bin ディレクトリーにあります。
  - java (Java インタープリター)
    - Java クラスを実行します。 Java インタープリターが、Java プログラム言語で書かれたプログラムを 実行します。
  - javaw (Java インタープリター)
    - Java コマンドと同様の方法で Java クラスを実行しますが、 コンソール・ウィンドウは使用しません。
  - keytool (鍵および証明書管理ツール)
    - 秘密鍵の鍵ストア (データベース) とそれに関連した X.509 証明書チェーン (対応する公開鍵を認証する) を 管理します。
  - policytool (ポリシー・ファイルの作成と管理ツール)
    - ご使用のインストール済み環境での Java セキュリティー・ポリシーを定義する 外部ポリシー構成ファイルを作成し変更します。
  - rmid (RMI アクティベーション・システム・デーモン)
    - オブジェクトを登録し、Java 仮想マシン (JVM) で活動化できるように、 アクティベーション・システム・デーモンを開始します。
  - tnameserv (Common Object Request Broker Architecture (CORBA) ネーミング・サービス)
    - CORBA 一時ネーミング・サービスを開始します。
  - rmiregistry (Java リモート・オブジェクト・レジストリー)
    - 現行ホストの指定ポートにリモート・オブジェクト・レジストリーを作成し、開始します。
  - ikeyman (iKeyman GUI ユーティリティー)
    - これにより、鍵、証明書、および認証要求を管理できます。詳しくは、 付随する「Security Guide (英語)」および http://www.ibm.com/developerworks/java/jdk/security を参照してください。また、SDK には、 このユーティリティーのコマンド行バージョンもあります。 詳細は、『iKeyman のアクセシビリティ』を参照してください。
  - jextract (ダンプ抽出)
    - システム生成ダンプを jdmpview で使用できる共通フォーマットに 変換します。 詳しくは、「Diagnostics Guide (英語)」を参照してください。
  - (Linux IA 32 ビット、PPC32、および PPC64 のみ) javaws (Java Web Start)
    - Java アプリケーションの配置と自動保守を可能にします。
  - (Linux IA 32 ビット、PPC32、および PPC64 のみ) |updateSettings.sh (Java Web Start の設定)
    - ブラウザーで Web Start を使用するようにシステムを構成します。詳しくは、『Web Start の実行』を参照してください。 このファイルは、jre/lib/javaws ディレクトリーにインストールされます。

## SDK ツール

- 以下のツールは、SDK の一部で、/opt/ibm/java2-i386-50/bin ディレクトリーに配置されています。
  - javac (Java コンパイラー)
    - Java プログラム言語で書かれたプログラムをバイトコード (コンパイル済み Java コード) に コンパイルします。
  - appletviewer (Java アプレット・ビューアー)
    - Web ブラウザーの外部でアプレットをテスト、実行します。
  - jdb (Java デバッガー)
    - Java プログラムのデバッグに役立ちます。
  - javap (クラス・ファイルの逆アセンブラー)
    - コンパイル済みファイルを逆アセンブルし、バイトコード表記を表示できます。
  - javadoc (Java ドキュメンテーション・ジェネレーター)
    - Java ソース・ファイルから API ドキュメンテーションの HTML ページを生成します。
  - javah (C ヘッダーおよびスタブ・ファイル・ジェネレーター)
    - これにより、ネイティブ・メソッドを Java プログラム言語で書かれたコードに関連付けることができます。
  - jar (Java Archive ツール)
    - 複数ファイルを単一の Java Archive (JAR) ファイルに結合させます。
  - jarsigner (JAR 署名および検証ツール)
    - JAR ファイルの署名を生成し、署名付き JAR ファイルの署名を検証します。
  - jconsole (JConsole モニターおよび管理ツール - 試験的)
    - ローカルおよびリモート JVM をモニターするための試験的な (サポートされない) JMX 準拠グラフィック・ツール
  - native2ascii (Native-To-ASCII コンバーター)
    - ネイティブ・エンコード・ファイルを Latin 1 または Unicode またはその両方にエンコードされている 文字を含む ASCII ファイルに変換します。
  - rmic (Java Remote Method Invocation (RMI) スタブ・コンバーター)
    - リモート・オブジェクトのスタブ、スケルトン、およびタイを生成します。Internet Inter-ORB Protocol (RMI-IIOP) 上の RMI サポートも含みます。
  - java-rmi.cgi (HTTP-to-CGI 要求転送ツール)
    - RMI-over-HTTP 要求を受信し、任意のポートで listen している RMI サーバーにそれらを転送します。
  - idlj (IDL から Java コンパイラーへ)
    - 指定の IDL ファイルから Java バインディングを生成します。
  - serialver (直列化バージョン・コマンド)
    - 新しいクラスへのコピーに適切な形式で、1 つ以上のクラスの serialVersionUID を戻します。
  - extcheck (Extcheck ユーティリティー)
    - ターゲット JAR ファイルと現在インストール済みの拡張 JAR ファイル間のバージョンの矛盾を検出します。
  - jdmpview (クロスプラットフォーム・ダンプ・フォーマッター)
    - ダンプの分析を可能にするツール。詳しくは、「Diagnostics Guide (英語)」を参照してください。
  - (Linux IA 32 ビット、PPC32、および PPC64 のみ) htmlconverter (Java Plug-in HTML コンバーター)
    - アプレットを含む HTML ページを Java Plug-in を使用できるフォーマットに変換します。
- INCLUDE ファイル
  - JNI プログラムの C ヘッダー
- デモ
  - demo ディレクトリーには、ユーザーが使用できるサンプル・ソース・コード、デモ、アプリケーション、 およびアプレットが入った多くのサブディレクトリーがあります。
- 著作権
  - SDK for Linux ソフトウェアの著作権表示。
- ライセンス
  - ライセンス・ファイル /opt/ibm/java2-i386-50/docs/<locale>/license_<locale>.html に SDK for Linux ソフトウェアのご使用条件が含まれています (ここで <locale> は、例えば En_US などの、ご使用のロケールの名前です)。ご使用条件を 表示あるいは印刷するには、Web ブラウザーでこのファイルをオープンしてください。
- FIXES.LST
  - このバージョンの初期リリースの後に修正された問題を説明するテキスト・ファイル。

注: この SDK for Linux に組み込まれているドキュメンテーションは、 ユーザー・ガイド、Javadoc、および付随するライセンス、著作権ファイル、デモ・ディレクトリーのみです。 Sun の Web サイトにアクセスして Sun のソフトウェア・ドキュメンテーションを表示するか、 あるいは、Sun の Web サイト http://java.sun.com から Sun の ソフトウェア・ドキュメンテーション・パッケージをダウンロードすることができます。

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

IBM Java SDK and Runtime Environment は、RPM または .tgz ファイルからインストールすることができます。 マシン上の全ユーザーがこの Java インストール済み環境にアクセスできるようにする場合を除いて、 .tgz のインストール方式を使用します。 root アクセス権限を持たない場合は、.tgz ファイルを使用してください。

RPM ファイルを使用してインストールした場合、Java ファイルは /opt/ibm/java2-i386-50/ にインストールされます。 このガイドの例は、このディレクトリーに Java をインストール済みであることを前提としています。

## Red Hat Enterprise Linux (RHEL) 4 でのインストール

SDK は、Red Hat Enterprise Linux (RHEL) 4.0 にデフォルトでインストールされない共用ライブラリーに依存しています。

これらのライブラリーを含む RPM は、以下のものです。

- `compat-libstdc++-33-3.2.3` および `xorg-x11-deprecated-libs-6.8.1` (Intel アーキテクチャー、PPC、および PPC64)
- `compat-libstdc++-295-2.95.3` および `xorg-x11-deprecated-libs-6.8.1` (zSeries)

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

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

| | |

## 64 ビット・アーキテクチャーでの 32-bit SDK のインストール

|

SDK を実行するには、その 32-bit SDK または 64-bit SDK |が必要とする正しいバージョンの全ライブラリーをインストールする必要があります。

|

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 ファイルからのインストール

1. root でログオンしていること確認して、シェル・プロンプトをオープンします。
2. シェル・プロンプトで、`rpm -ivh <RPM file>` を入力します。例えば、次のようにします。

       |rpm -ivh ibm-java2-<arch>-sdk-5.0-0.0.<arch>.rpm

   または

       |rpm -ivh ibm-java2-<arch>-jre-5.0-0.0.<arch>.rpm

   |ここで、`<arch>` はご使用のアーキテクチャー |i386、x86_64、ppc、ppc64、s390、または s390x を表します。

## .tgz ファイルからのインストール

1. Java パッケージ・ファイルを保管するディレクトリーを作成します。 このガイドの例は、/opt/ibm/java2-i386-50/ にインストール済みであることを前提としています。 このガイドでこれ以降、/opt/ibm/java2-i386-50/ は Java をインストールしたディレクトリーに置き換えてください。
2. シェル・プロンプトで、`tar -zxvf <.tgz file>` を入力します。例えば、次のようにします。

       |tar -zxvf ibm-java2-sdk-50-linux-<arch>.tgz

   または

       |tar -zxvf ibm-java2-jre-50-linux-<arch>.tgz

   |ここで、`<arch>` はご使用のアーキテクチャー |i386、x86_64、ppc、ppc64、s390、または s390x を表します。

## SDK and Runtime Environment for Linux の構成

### PATH の設定

PATH 環境変数を以下に示すように変更する場合、ご使用のパスにある既存の Java 実行可能ファイルを オーバーライドすることに注意してください。

SDK をインストールした後は、シェル・プロンプトでツールの名前を入力し、 ファイル名を引数に指定して、ツールを使用できます。

ツールへのパスは、その都度、ツール名の前にパスを入力して指定します。 例えば、SDK for Linux が /opt/ibm/java2-i386-50/bin にインストールされている場合、myfile.java という名前のファイルを コンパイルするには、シェル・プロンプトで以下のように入力します。

      /opt/ibm/java2-i386-50/bin/javac myfile.java

PATH 環境変数を変更するには、次のようにします。

1. ホーム・ディレクトリーにあるシェル始動ファイル (ご使用のシェルによりますが、通常は、.bashrc) を編集し、 PATH 環境変数に絶対パスを追加してください。例えば、次のようにします。

       export PATH=/opt/ibm/java2-i386-50/bin:/opt/ibm/java2-i386-50/jre/bin:$PATH

2. 再びログオンするか、または、更新したシェル・スクリプトを実行して、新しい PATH 設定をアクティブにします。

### CLASSPATH の設定

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

以下のいずれかが該当する場合のみ、CLASSPATH を明示的に設定する必要があります。

- 例えば、独自に作成したものなど異なるライブラリーまたはクラス・ファイルが必要であり、それが現行ディレクトリーにない場合。
- bin および lib ディレクトリーの位置を変更して、同じ共通の親ディレクトリーがもはやない場合。
- 同一システム上に異なるランタイム環境を使用する複数のアプリケーションを作成し実行する予定の場合。

ご使用の CLASSPATH の現行値を表示するには、 シェル・プロンプトで、次のように入力します。

      echo $CLASSPATH

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

一度に 1 つのバージョンの Java のみ実行する場合は、 シェル・スクリプトを使用して、異なる ランタイム環境を切り替えることができます。

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

## 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) パッケージのアンインストール

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

1. シェル・プロンプトで以下を行います。
   1. インストール済みの RPM パッケージを確認するために、以下を入力します。

          rpm -qa | grep -i java

   2. インストール済みの IBM Java パッケージのリストが表示されます。 例えば、次のようになります。

          ibm-java2-<arch>-jre-5.0-0.0.<arch>
          ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   3. この出力は、`rpm -e` コマンドを使用して、アンインストールできるパッケージを示します。 例えば、次のようになります。

          rpm -e ibm-java2-<arch>-jre-5.0-0.0.<arch>
          rpm -e ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   代わりに、kpackage あるいは yast2 などのグラフィック・ツールを使用することもできます。
2. PATH ステートメントから、SDK および Runtime Environment をインストールしているディレクトリーを除去します。
3. (Linux IA 32 ビットおよび PPC32 のみ)Java Plug-in をインストールしていた場合は、Web ブラウザー・ディレクトリーから Java Plug-in のファイルを除去します。

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

圧縮された TAR パッケージを解凍している場合に、Linux の SDK または Runtime Environment を アンインストールするには以下のようにします。

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

# Runtime Environment の使用

java ツールは、Java Runtime Environment を開始し、指定されたクラスをロードすることによって、 Java アプリケーションを起動します。

JVM は、初期クラス (および使用されるその他のクラス) を、ブートストラップ・クラスパス、 インストールされた拡張機能、ユーザー・クラスパスの 3 カ所で検索します。 クラス名または JAR ファイル名の後に指定する引数が、main 関数に渡されます。

javaw コマンドは、javaw には関連するコンソール・ウィンドウがないことを除いて、java と同一です。 コマンド・プロンプト・ウィンドウを表示したくない場合には javaw を使用してください。 javaw ランチャーは、起動に失敗した場合に、エラー情報を含むダイアログ・ボックスを表示します。

java および javaw コマンドの構文は次のとおりです。

    java [ options ] class [ arguments ... ]
    java [ options ] -jar file.jar [ arguments ... ]
    javaw [ options ] class [ arguments ... ]
    javaw [ options ] -jar file.jar [ arguments ... ]

大括弧で囲まれている項目はオプショナルです。

options
  コマンド行オプション。
class
  呼び出すクラスの名前。
file.jar
  呼び出す JAR ファイルの名前。 -jar でのみ使用されます。
arguments
  main 関数に渡される引数。

-jar オプションが指定された場合には、指定された JAR ファイルにアプリケーションのクラスおよびリソース・ファイルが入っていて、始動クラスは Main-Class マニフェスト・ヘッダーで示されています。

## オプション

ランチャーには、現在の Runtime Environment でサポートされ、将来のリリースでサポートされる標準オプションのセットがあります。 このほかに、非標準オプションのセットがあります。 デフォルト・オプションは、最も一般的な使用法に応じて選択されています。 変更する場合には注意してください。

### Java オプションおよびシステム・プロパティーの指定

Java オプションおよびシステム・プロパティーを指定するには、3 つの方法があります。 それらは、優先順に以下のものです。

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

コマンド行では、右端のオプションが左端のオプションより優位になります。 例えば、「`-Xint -Xjit myClass`」というオプションを指定した場合、 -Xjit が優位になります。

### 標準オプション

- -D<property_name>=<value>
  - システム・プロパティーを設定します。
- -assert
  - assert 関連オプションのヘルプを表示します。
- -cp または -classpath <: で区切られたディレクトリーおよび ZIP ファイルまたは JAR ファイル>
  - アプリケーション・クラスおよびリソースの検索パスを設定します。-classpath も -cp も使用しないで、CLASSPATH を設定しないと、ユーザー・クラスパスは、デフォルトでは現行ディレクトリー (.) です。
- -help または -?
  - 使用法メッセージを表示します。
- -showversion
  - 製品のバージョンを表示して継続します。
- -verbose:[class,gcterse,gc,dynload,stackwalk,sizes,stack,debug,jni]
  - 詳細出力を使用可能にします。
- -version
  - 製品のバージョンを表示します。
- -version:<value>
  - 指定したバージョンの実行を要求します。
- -jre-restrict-search
  - バージョン検索でユーザーのプライベート JRE を含めます
- -no-jre-restrict-search
  - バージョン検索でユーザーのプライベート JRE を除外します
- -agentlib:<libname>[=<options>]
  - ネイティブ・エージェント・ライブラリー <libname> をロードします。 例えば、-agentlib:hprof のようにします。詳しくは、コマンド行で -agentlib:jdwp=help と -agentlib:hprof=help を指定してください。
- -agentpath:libname[=<options>]
  - 絶対パス名でネイティブ・エージェント・ライブラリーをロードします
- -javaagent:<jarpath>[=<options>]
  - Java プログラミング言語エージェントをロードします。詳しくは、java.lang.instrument API のドキュメンテーションを参照してください。
- -X
  - 非標準オプションのヘルプを表示します。

### 非標準オプション

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

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

- -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 2 Runtime Environment バイナリー・コードのライセンス違反になります。 デフォルトでは、内部の VM ディレクトリーおよび .jar ファイル内のブートストラップ・クラスおよびリソースを検索します。
- -Xcheck:jni
  - JNI 機能の追加検査を行います。-Xrunjnichk も使用できます。 デフォルトでは、検査が実行されません。
- -Xcheck:nabounds
  - JNI 配列操作の追加検査を行います。-Xrunjnichk も使用できます。 デフォルトでは、検査が実行されません。
- |-Xclassgc | |
  |
  - このオプションにより、ガーベッジ・コレクションごとのクラス・オブジェクトのコレクションを可能にします。 |デフォルトでは、このオプションは使用可能です。
- -Xcompactexplicitgc
  - `System.gc()` のすべての呼び出しで圧縮します。 -Xnocompactexplicitgc も参照してください。デフォルトでは、圧縮は内部的に起動されたときにのみに行われます。
- -Xcompactgc
  - すべてのガーベッジ・コレクター・サイクルを圧縮します。 -Xnocompactgc も参照してください。デフォルトでは、圧縮は内部的に起動されたときにのみに行われます。
- |-Xconcurrentbackground <number> | |
  |
  - このオプションは、ガーベッジ・コレクションの並行マーク・フェーズにおける mutator |スレッドを支援するために接続された、優先順位が低いバックグラウンド・スレッドの数を指定します。デフォルトは、1 です。
- |-Xconcurrentlevel <number> | |
  |
  - このオプションは、割り振り「負担」率を指定します。これは、割り振られたヒープの量と、 |マークされたヒープの量との比率を示します。デフォルトは、8 です。
- |-Xconmeter:<soa | loa | dynamic> | |
  |
  - このオプションは、LOA 域または SOA 域のどちらの使用率を測定し、 |それに従って、並行マーク中にどちらの割り振りに負担がかけられるかを決定します。 -Xconmeter:soa を使用すると、 |割り振り負担をスモール・オブジェクト域 (SOA) からの割り振りに適用し、 |-Xconmeter:loa を使用すると、 |割り振り負担をラージ・オブジェクト域 (LOA) からの割り振りに適用します。 -Xconmeter:dynamic が指定された場合、SOA でも LOA でも、 |どちらの領域が最初に使い尽くされたかに基づいて、どちらの領域を測定するかを、コレクターが動的に判断します。 | |デフォルトでは、このオプションは -Xconmeter:soa に設定されます。
- -Xdbg:<options>
  - アプリケーションのリモート・デバッグをサポートするデバッグ・ライブラリーをロードします。 これは、-Xrunjdwp と同じです。 デフォルトでは、デバッグ・ライブラリーはロードされず、VM インスタンスはデバッグについて使用可能でありません。
- -Xdbginfo:<path to symbol file>
  - オプションをデバッグ情報サーバーにロードして渡します。 デフォルトでは、デバッグ情報サーバーは使用不可です。
- -Xdebug
  - デバッガーを使用可能にして JVM を開始します。デフォルトでは、デバッガーは使用不可です。
- |-Xdisableexcessivegc |
  |
  - このオプションは、GC で過度の時間が費やされた場合の OutOfMemory 例外のスローを使用不可にします。 デフォルトでは、このオプションはオフです。
- -Xdisableexplicitgc
  - `System.gc()` を呼び出す VM へのシグナルが効力を持ちません。 デフォルトでは、`System.gc()` の呼び出しが、ガーベッジ・コレクションを起動します。
- |-Xdisablestringconstantgc |
  |
  - このオプションは、ストリング拘束テーブルのストリングが収集されないようにします。 |デフォルトでは、このオプションは使用不可です。
- -Xdisablejavadump
  - エラーおよびシグナルによる javadump 生成をオフにします。 デフォルトでは、javadump 生成は使用可能です。
- |-Xenableexcessivegc |
  |
  - GC で過度の時間が費やされた場合、このオプションは割り振り要求に対して NULL を戻し、 |それにより、OutOfMemory 例外のスローを引き起こします。このアクションは、ヒープがいっぱいに拡張されて、費やされた時間が少なくとも 95% |になっている場合にのみ行われます。 |この振る舞いはデフォルトです。
- |-Xenablestringconstantgc |
  |
  - このオプションは、ストリング拘束テーブルのストリングを収集できるようにします。 |デフォルトでは、このオプションは使用可能です。
- -Xfuture
  - 厳密なクラス・ファイル・フォーマット検査をオンにします。 将来のリリースでより厳密な検査がデフォルトになるため、 新しいコードの開発時にこのフラグを使用します。 デフォルトでは、厳密なフォーマット検査は使用不可です。
- -Xgcpolicy:[optthruput]|[optavgpause]|[gencon]||[subpool] (PPC および zSeries 上のサブプール)
  - ガーベッジ・コレクターの振る舞いを制御します。 optthruput オプションがデフォルトで、非常に高いスループットをアプリケーションに提供しますが、 代償として時折休止します。optavgpause オプションは、 これらのガーベッジ・コレクション休止に費やされる時間を削減し、 ヒープ・サイズの増加がガーベッジ・コレクション休止の長さに与える影響を制限します。 非常に大規模なヒープが構成にある場合には、optavgpause を使用します。 gencon オプションは、並行と世代別の GC を組み合わせた使用を要求し、 ガーベッジ・コレクションの休止に費やされる時間を最小にするよう支援します。 |subpool オプションは、 |改良されたオブジェクト割り振りアルゴリズムを使用して、 |ヒープでのオブジェクトの割り振り時にパフォーマンスを向上させます。 |このオプションは、大規模な SMP システムでパフォーマンスを向上させる可能性があります。 詳しくは、『ガーベッジ・コレクション・ポリシーの指定』を参照してください。
- -Xgcthreads<number of threads>
  - ガーベッジ・コレクション中、並列操作に使用されるヘルパー・スレッドの数を設定します。 デフォルトでは、スレッドの数は、存在する物理 CPU の数から 1 を引いた数に設定され、最小が 1 になります。
- |-Xgcworkpackets <number> |
  |
  - このオプションは、グローバル・コレクターで使用可能な作業パケットの総数を指定します。 |指定されないと、コレクターは、最大ヒープ・サイズに基づいてパケットの数を割り振ります。
- -Xint
  - JVM にインタープリターのみを使用させ、Just-In-Time (JIT) コンパイラーを使用不可にします。 デフォルトでは、JIT コンパイラーは使用可能です。
- -Xiss<size>
  - 初期の Java スレッド・スタック・サイズを設定します。デフォルトで 2 K バイトです。
- -Xjit[:<suboption>,<suboption>,...]
  - JIT を使用可能にします。サブオプションの詳細については、「Diagnostics Guide (英語)」を参照してください。-Xnojit も参照してください。デフォルトでは、JIT は使用可能です。
- -Xlinenumbers
  - デバッグのために、スタック・トレース内の行番号を表示します。 -Xnolinenumbers も参照してください。 デフォルトでは、行番号はオンです。
- |-Xloa |
  |
  - このオプションは、ラージ・オブジェクト域 (LOA) を割り振ります。 |オブジェクトは、SOA でなく、この LOA に割り振られます。 |デフォルトでは、LOA が使用可能でないサブプールを除いて、すべての GC ポリシーに LOA が使用可能です。 |-Xnoloa も参照してください。
- |-Xloainitial <number> |
  |
  - <number> は、0 から 0.95 で、 |ラージ・オブジェクト域 (LOA) に割り振られる古い世代の現行スペースの初期パーセンテージを指定します。 |デフォルトは 0.05、つまり 5% です。
- |-Xloamaximum <number> |
  |
  - <number> は、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<size>
  - ガーベッジ・コレクション後にフリーである必要があるヒープの最大パーセンテージを指定します。 フリー・スペースがこの量を超えると、JVM がヒープの縮小を試行します。 サイズは 0 から 1 の範囲の小数値で指定します。 例えば、`-Xmaxf0.5` は最大フリー・スペースを 50 % に設定します。 デフォルト値は 0.6 (60 %) です。
- -Xmca<size>
  - RAM 部分のロードされたクラスを保管するために割り振られるメモリーに対する、拡張の差分を設定します。 RAM 内のクラスの保管にさらにメモリーが必要になるたびに、 割り振りメモリーがこの量の分、増加されます。デフォルトでは、拡張の差分は 32 K です。
- -Xmco<size>
  - ROM 部分のロードされたクラスを保管するために割り振られるメモリーに対する、拡張の差分を設定します。 ROM 内のクラスの保管にさらにメモリーが必要になるたびに、 割り振りメモリーがこの量の分、増加されます。デフォルトでは、拡張の差分は 128 K です。
- -Xmine<size>
  - ガーベッジ・コレクターがヒープを拡張する差分の最小量を設定します。 通常、ガーベッジ・コレクターは、フリー・スペースを 30 % (または -Xminf で指定された量) に戻すのに必要な量の分、ヒープを拡張します。 -Xmine オプションは、拡張を少なくとも指定された値に設定します。 例えば、`-Xmine50M` では、拡張サイズが最小で 50 MB に設定されます。 デフォルトでは、最小の拡張サイズは 1 MB です。
- -Xminf<size>
  - ガーベッジ・コレクション後にフリーである必要があるヒープの最小パーセンテージを指定します。 フリー・スペースがこの量を切ると、JVM がヒープの拡張を試行します。 サイズは 0 から 1 の範囲の小数値で指定します。 例えば、`-Xminf0.3` という値では、最小フリー・スペースをヒープの 30% にするよう要求します。 デフォルトでは、最小値は 0.3 です。
- -Xmn<size>
  - -Xgcpolicy:gencon の使用時に、 新しい世代のヒープの初期および最大サイズを、指定された値に設定します。 -Xmns と -Xmnx の両方を設定することと同等です。 |-Xmns または -Xmnx を設定した場合、 |-Xmn は設定できません。 |-Xmns または -Xmnx とともに |-Xmn を設定しようとすると、VM が始動せず、エラーが戻ります。 デフォルトでは、-Xmn はシステムの能力に従って内部的に選択されます。 -verbose:sizes オプションを使用して、VM が現在使用している値を検出できます。
- -Xmns<size>
  - -Xgcpolicy:gencon の使用時に、新しい世代のヒープの初期サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 |このオプションを -Xmn とともに使用しようとすると、エラーが戻ります。
- -Xmnx<size>
  - -Xgcpolicy:gencon の使用時に、新しい世代のヒープの最大サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 |このオプションを -Xmn とともに使用しようとすると、エラーが戻ります。
- -Xmo<size>
  - -Xgcpolicy:gencon の使用時に、 古い世代のヒープの初期および最大サイズを、指定された値に設定します。 -Xmos と -Xmox の両方を設定することと同等です。 |-Xmos または -Xmox を設定した場合、 |-Xmo は設定できません。-Xmos または -Xmox とともに |-Xmo を設定しようとすると、VM が始動せず、エラーが戻ります。 デフォルトでは、-Xmo はシステムの能力に従って内部的に選択されます。 -verbose:sizes オプションを使用して、VM が現在使用している値を検出できます。
- -Xmos<size>
  - -Xgcpolicy:gencon の使用時に、古い世代のヒープの初期サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 |このオプションを -Xmo とともに使用しようとすると、エラーが戻ります。
- -Xmox<size>
  - -Xgcpolicy:gencon の使用時に、古い世代のヒープの最大サイズを、指定された値に設定します。 デフォルトでは、このオプションはシステムの能力に従って内部的に選択されます。 |このオプションを -Xmo とともに使用しようとすると、エラーが戻ります。
- -Xmoi<size>
  - -Xgcpolicy:gencon の使用時に、Java ヒープの増分量を設定します。 ゼロに設定されると、拡張はできません。 デフォルトでは、増分サイズは、拡張サイズ -Xmine および -Xminf を基に計算されます。
- -Xmr<size>
  - -Xgcpolicy:gencon の使用時に、ガーベッジ・コレクションの「remembered set」のサイズを設定します。 これは、新しい世代のヒープ内のオブジェクトへの参照を持つ、 古い世代のヒープ内のオブジェクトのリストです。 デフォルトでは、このオプションは 16 K バイトに設定されます。
- -Xms<size>
  - 初期の Java ヒープ・サイズを設定します。 -Xmo も使用できます。 デフォルトは、システムの能力に従って内部的に設定されます。
- -Xmso<size>
  - fork された Java スレッドの C スタック・サイズを設定します。 デフォルトでは、このオプションは、32 ビット・プラットフォームでは 32 K バイト、 64 ビット・プラットフォームでは 256 K バイトに設定されます。
- -Xmx<size>
  - 最大 Java ヒープ・サイズを設定します。デフォルトでは、このオプションはシステムの能力に従って内部的に設定されます。
- -Xnoclassgc
  - クラス・ガーベッジ・コレクションを使用不可にします。これは、JVM によってもう使用されない Java クラスに関連付けられたストレージのガーベッジ・コレクションをオフに切り替えます。 デフォルトの振る舞いは -Xclassgc です。
- -Xnocompactgc
  - ガーベッジ・コレクターの圧縮を使用不可にします。 -Xcompactgc も参照してください。 デフォルトでは、圧縮は使用可能です。
- -Xnocompactexplicitgc
  - `System.gc()` の呼び出しで圧縮を使用不可にします。 -Xcompactexplicitgc も参照してください。 デフォルトでは、`System.gc()` の呼び出しで圧縮は使用可能です。
- -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 と同じです。 詳しくは、『Java アプリケーションのデバッグ』を参照してください。
    - -Xrunjnichk[:help] | [:<option>=<value>, ...]
      - JNI 機能の追加検査を実行し、JNI を使用して JVM にアクセスするネイティブ・プログラムでのエラーをトレースします。 詳しくは、「Diagnostics Guide (英語)」を参照してください。
- |-Xscmx<size>[k|m|g] | |
  |
  - -Xscmx の詳細については、『クラス共用のためのコマンド行オプションの使用』を参照してください。
- |-Xshareclasses:<suboptions> | |
  |
  - -Xshareclasses サブオプションの詳細については、 |『クラス共用のためのコマンド行オプションの使用』を参照してください。
- -Xsigcatch
  - VM シグナル処理コードを使用可能にします。 -Xnosigcatch も参照してください。 デフォルトでは、シグナル処理は使用可能です。
- -Xsigchain
  - シグナル・ハンドラーのチェーニングを使用可能にします。 -Xnosigchain も参照してください。 デフォルトでは、シグナル・ハンドラーのチェーニングは使用可能です。
- |-Xsoftrefthreshold<number> | |
  |
  - このオプションは、対象がマークされていない場合にソフト参照がクリアされるまでの |GC の数を設定します。デフォルトは 3 です。これは、対象がマークされていない 3 番目の GC で、 |ソフト参照がクリアされることを意味します。
- -Xss<size>
  - スレッドの最大 Java スタック・サイズを設定します。デフォルトでは、このオプションは 256 KB に設定されます。詳しくは、『浮動スタックの処理』を参照してください。
- -Xthr:<options>
  - スレッド化オプションを設定します。
- -Xverbosegclog:<path to file><filename>[X, Y]
  - verboseGC の出力を指定したファイルに書き込みます。ファイルがすでに存在していると、上書きされます。それ以外の場合で、既存ファイルを開けないか、新しいファイルを作成できない場合は、出力は stderr にリダイレクトされます。引数 X および Y (両方とも整数) を指定すると、 verboseGC 出力は X 個のファイルにリダイレクトされ、それぞれのファイルには、Y 個の gc サイクルの verboseGC 出力が含まれます。これらのファイルは、filename1、filename2、... という形式になります。デフォルトでは、詳細ガーベッジ・コレクション・ロギングは行われません。
- -Xverify
  - ロードされたすべてのクラスに対して厳密なクラス検査を使用可能にします。 デフォルトでは、厳密なクラス検査は使用不可です。
- -Xverify:none
  - 厳密なクラス検査を使用不可にします。 デフォルトでは、厳密なクラス検査は使用不可です。

## IBM ビルド番号およびバージョン番号の取得

IBM ビルド番号およびバージョン番号を確認するには、シェル・プロンプトで以下を入力してください。

    java -version

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

java コマンドやその他の java ランチャー・コマンド (javaw など) では、クラス名を現行ロケールの文字セット内の任意の文字で指定できます。

また、Java エスケープ・シーケンスを使用して、クラス名と引数に任意の Unicode 文字を指定することもできます。 これを行うには、-Xargencoding を指定する必要があります。 Unicode 文字を指定するには、エスケープ・シーケンスを `¥u####` の形式で使用します。ここで # は 16 進数字 (0 から 9、A から F) です。

あるいは、クラス名およびコマンド引数が UTF8 エンコード方式であることを指定するには -Xargencoding:utf8 を、ISO8859_1 エンコード方式であることを指定するには -Xargencoding:latin を使用します。

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

    java -Xargencoding '¥u0048ello¥u0057orld'

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

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

IBM Just-In-Time (JIT) コンパイラーは、Java アプリケーションやアプレットで実行中に頻繁に使用される バイトコード・シーケンスのマシン・コードを動的に生成します。 |JIT V5.0 コンパイラーは、コンパイラーの研究によって新しい最適化を実現し、 |前のバージョンの JIT に実装されていた最適化を改良して、ハードウェアをより大きく活用しています。

IBM SDK and Runtime Environment には JIT が含まれており、SDK ツールのほかユーザー・アプリケーションにおいても、 デフォルトで使用可能に設定されています。 通常、明示的に JIT を起動する必要はありません。 Java バイトコードからマシン・コードへのコンパイルは、透過的に行われます。 ただし、Java アプリケーションまたはアプレットを実行中に Runtime Environment で問題が発生した場合には、問題の切り分けのために JIT を使用不可にすることができます。 JIT を使用不可にするのは、一時的な手段のみにしてください。 JIT は、適切なパフォーマンスを得るために必要です。

### JIT の使用不可化

JIT を使用不可にするには 3 つの方法があります。

- Java アプリケーションを実行する前に、JAVA_COMPILER 環境変数に "NONE" または空ストリングを設定します。

  コマンド・プロンプトで次のように入力します。

  1. Korn シェルの場合:

     -     export JAVA_COMPILER=NONE

       (このユーザー・ガイドでは、以降、Korn シェル・コマンドを使用します。)

  2. Bourne シェルの場合:

     -     JAVA_COMPILER=NONE

     -     export JAVA_COMPILER

  3. C シェルの場合:

     -     setenv JAVA_COMPILER NONE

- JVM コマンド行で -D オプションを使用して、 java.compiler プロパティーに "NONE" または空ストリングを設定します。

      java -Djava.compiler=NONE MyApp

- JVM コマンド行で -Xint オプションを使用します。例えば、次のようにします。

      java -Xint MyApp

どちらのコマンド行オプションも、JAVA_COMPILER 環境変数をオーバーライドします。

### JIT の使用可能化

明示的に JIT を使用可能にするには、JAVA_COMPILER 環境変数に "jitc" を設定するか、または、-D オプションを使用して java.compiler プロパティーに "jitc" を設定します。 あるいは、JVM コマンド行で -Xjit オプションを使用 (かつ -Xint オプションは省略) して JIT をオンにします。

JAVA_COMPILER 環境変数または java.compiler プロパティーに "" (空ストリング) が設定されている場合、 JIT は使用不可のままになります。 環境変数を適切に設定解除するには、 シェル・プロンプトで `unset JAVA_COMPILER` を入力します。

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

JIT が使用可能かどうかを判別するには、コマンド・プロンプトで次のように入力します。

        java -version

JIT が使用できない場合には、以下の内容のメッセージが表示されます。

    (JIT disabled)

JIT が使用できる場合には、以下の内容のメッセージが表示されます。

    (JIT enabled)

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

## ガーベッジ・コレクション・ポリシーの指定

ガーベッジ・コレクターは、Java が使用するメモリーおよび VM 内で稼働するアプリケーションが使用するメモリーを管理します。

ガーベッジ・コレクターはストレージの要求を受け取ると、ヒープ内の未使用メモリーを引き当てます。すなわち、 「割り振り」です。 また、ガーベッジ・コレクターは、もはや参照されていないメモリー領域を確認し、それらを再利用のために 解放します。これがすなわち「コレクション」です。

コレクション・フェーズは、メモリーの割り振り障害がトリガーとなって起動されます。割り振り障害は、 ストレージ要求に対してスペースが残っていない場合に発生するか、または、明示的な System.gc() 呼び出しによっても 引き起こされます。

ガーベッジ・コレクションは、アプリケーションのパフォーマンスに大きく影響するので、 IBM 仮想マシンは、ガーベッジ・コレクション実行の方法を最適化するためにさまざまな メソッドを提供して、アプリケーションへの影響を削減するようにしています。

ガーベッジ・コレクションに関する詳細情報は、「Diagnostics Guide (英語)」を参照してください。

### ガーベッジ・コレクションのオプション

-Xgcpolicy オプションは、ガーベッジ・コレクション・ポリシーを指定します。

-Xgcpolicy は、値として optthruput (デフォルトおよび推奨値)、optavgpause|、subpool| (PPC および |zSeries のみ)、または gencon を使用します。このオプションは、 ガーベッジ・コレクターの動作を制御して、アプリケーションおよびシステム全体のスループットと ガーベッジ・コレクションに起因する休止時間とのトレードオフを図ります。

このオプションのフォーマットと値は次のとおりです。

> -Xgcpolicy:optthruput

> -Xgcpolicy:optavgpause

> -Xgcpolicy:gencon

|

> -Xgcpolicy:subpool (PPC および zSeries のみ)

### 休止時間

アプリケーションがオブジェクトを作成しようとして、その要求がヒープ内の使用可能スペースの理由で すぐに実現しない場合に、ガーベッジ・コレクターは、参照されていないオブジェクト (ガーベッジ) を 識別してそれらを削除し、ヒープの状態を即時および後続の割り振り要求にすぐに応じられる状態に 戻す責任があります。 そうしたガーベッジ・コレクションの繰り返しにより、アプリケーション・コードの実行時に 予期しない休止が時々起こることがあります。 アプリケーションは大きく複雑になってきており、ヒープもそれに応じて大規模になっているので、このガーベッジ・コレクション休止時間は長さも重要度も増す傾向にあります。 デフォルトの ガーベッジ・コレクション値の -Xgcpolicy:optthruput では、 非常に高いスループットがアプリケーションにもたらされますが、 こうした一時休止 (ヒープ・サイズとガーベッジの質により数ミリ秒からかなりの秒数まであり得る) が 代償になっています。

### 休止時間の削減

JVM は、一時休止時間を削減するために 2 つの手法を使用します。

- 並行ガーベッジ・コレクション
- 世代別ガーベッジ・コレクション

-Xgcpolicy:optavgpause コマンド行オプションは、並行ガーベッジ・コレクションの 使用を要求し、ガーベッジ・コレクションの一時休止にあてられる時間を大幅に削減します。 並行ガーベッジ・コレクション (GC) は、一部のガーベッジ・コレクション・アクティビティーを 通常のプログラム実行と並行して行うことにより、ヒープのコレクションが原因で起きる中断を最小限に して、一時休止時間の削減を図ります。 また、-Xgcpolicy:optavgpause オプションは、ヒープ・サイズの増加が ガーベッジ・コレクション休止の長さに与える影響を制限します。 -Xgcpolicy:optavgpause オプションは、大容量のヒープを抱える構成の場合に 非常に有効です。 休止時間を削減することによって、アプリケーションのスループットがある程度縮小される場合があります。

並行ガーベッジ・コレクション時に、比較的長く存続していて収集できないオブジェクトの識別に かなりの時間が無駄に使われています。 GC が、リサイクル可能な傾向のあるオブジェクトのみに集中すれば、一部のアプリケーションへの 一時休止時間をさらに削減することができます。 世代別 GC は、ヒープを 2 つの「世代」、すなわち、 「新しい世代」と「古い世代」の領域に分けることでこれを実現します。 オブジェクトはその経過時間によって、この領域のどちらかに入れられます。 新しい世代領域は、2 領域の小さい方で、若いオブジェクトが入ります。一方、古い世代領域は、 大きい方で、古いオブジェクトが入ります。 オブジェクトは、まず、新しい世代領域に割り振られて、 長期間存続した場合に、最終的に古い世代領域にレベル上げされます。

世代別 GC は、長期間存続しない多くのオブジェクトに依存しています。 世代別 GC は、 多くのリサイクル可能なスペースを保有する、新しい世代領域のストレージを再利用することに 活動を集中させて、一時休止時間を削減します。 ヒープ全体をコレクションするために時折でも長い休止時間をとるのではなく、新しい世代を より頻繁に収集するので、新しい世代領域が小さければ、休止時間も比較的短くなります。 しかし、世代別 GC は、時間が経過すると存続期間が長いオブジェクトが非常に多くなり 古い世代領域が満杯になる可能性があるという欠点があります。 そうした状態が発生したときに一時休止時間を最小限にするために、並行 GC と世代別 GC を組み合わせて 使用してください。 -Xgcpolicy:gencon オプションで、ガーベッジ・コレクションの一時休止の時間を 最小限にするために、並行 GC と世代別 GC を組み合わせて使用することを要求します。

### ヒープが満杯の環境

Java ヒープが満杯に近く、再利用できるガーベッジが少ししかない場合、即時使用可能なスペースがないため、新規オブジェクト用の要求がすぐには満たされないことがあります。 ヒープが容量いっぱいに近い状態で操作されている場合、上記オプションのどちらが使用されているのかに関係なく、アプリケーション・パフォーマンスは悪くなります。 また、さらにヒープ・スペースの要求が続けば、アプリケーションはメモリー不足例外を受け取り、その例外がキャッチされ処理されなければ、JVM は終了します。 この時点で、 JVM は、javadump 診断ファイルを生成します。 このような状態の場合、-Xmx オプションを使用してヒープ・サイズを増やすか、使用中のアプリケーション・オブジェクトの数を減らすことをお勧めします。 詳しくは、「Diagnostics Guide (英語)」を参照してください。

## JVM によるシグナルの処理方法

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

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

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

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

- 状態を処理し、リカバリーする。あるいは、
- 以下を JVM が行った場合、制御されたシャットダウン・シーケンスに入る。
  1. 障害発生時点の JVM の状態を示す Javadump を出力する
  2. そのシグナルのためのユーザー・アプリケーションのシグナル・ハンドラーを呼び出す
  3. アプリケーションがインストールした何らかの打ち切りフックを呼び出す
  4. クリーン・シャットダウンのために必要なクリーンアップを実行する

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

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

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

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

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

### JVM が使用するシグナル

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

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

表 1. JVM が使用するシグナル
シグナル名 | シグナル・タイプ | 説明 | -Xrs による使用不可
--- | --- | --- | ---
SIGBUS | 例外 | メモリーに対する誤ったアクセス (データの調整ミス) | あり
SIGSEGV | 例外 | メモリーに対する誤ったアクセス (アクセス不能メモリーへの書き込み) | あり
SIGILL | 例外 | 正しくない命令 (不明なマシン・インストラクション呼び出しの試行) | なし
SIGFPE | 例外 | 浮動小数点例外 (ゼロ除算) | あり
SIGABRT | エラー | 異常終了。 JVM が JVM 障害を検出すると、このシグナルを生じさせます。 | あり
SIGINT | 割り込み | 対話式アテンション (CTRL-C)。 JVM は正常に終了します。 | あり
SIGTERM | 割り込み | 終了要求。 JVM は正常に終了します。 | あり
SIGHUP | 割り込み | ハングアップ。 JVM は正常に終了します。 | あり
SIGQUIT | 制御 | 端末用の終了シグナル。 JVM は、 Javadump を取るためにこれを使用します。 | あり
|SIGTRAP (5) | |制御 | |JIT が使用します。 | |あり
|__SIGRTMAX - 2 | |制御 | |SDK が使用します。 | |なし
|SIGCHLD | |制御 | |内部制御のために SDK が使用します。 | |なし

-Xrs (シグナル使用の削減) オプションを使用して、 JVM がほとんどのシグナルを処理してしまうのを防止します。詳しくは、 http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html にある、Sun の Java アプリケーション・ランチャーのページを参照してください。

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 をターゲットとしたものではないことが分かった場合、プリインストールされたハンドラーが起動します。

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

- 以下のように、JVM を作成または組み込むアプリケーションとリンクします。

      gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.c

  または
- 以下のように、LD_PRELOAD 環境変数を使用します。

      export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash and ksh)

      setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)

  (`JAVA_HOME` がすでに設定済みであると想定しています。 設定されていない場合には、/opt/ibm/java2-i386-50/jre を使用します。)

`sigaction()` を使用するシグナル・ハンドラーをインストールしている場合、JVM がシグナルを使用するときに、一部の sa_flags は見ることができません。これらは、以下のものです。

- SA_NOCLDSTOP - これは常に設定解除になっています。
- SA_NOCLDWAIT - これは常に設定解除になっています。
- SA_RESTART - これは常に設定されています。

libjsig.so ライブラリーも、 アプリケーションから JVM シグナル・ハンドラーを隠します。このため、JVM が開始した後で行われた `signal()`、`sigset()`、および `sigaction()` などの呼び出しでは、JVM のシグナル・ハンドラーへの参照を戻すことがなくなりますが、JVM の開始前にインストールされたハンドラーがあれば、代わりにそれを戻します。

## 浮動スタックの処理

特定の Linux ディストリビューション (例えば Red Hat) では、「浮動スタック」と呼ばれる GLIBC 機能が使用可能になっています。Linux のカーネルの制限により、カーネル・レベルが 2.4.10 未満の場合 JVM は、浮動スタックを使用可能にした SMP ハードウェア上では動作しません。 この環境では、JVM が開始される前、あるいは JVM を開始するアプリケーションが開始される前に、 浮動スタックは使用不可にされている必要があります。 Red Hat の場合は、次のコマンドを使用して環境変数をエクスポートして、浮動スタックを使用不可に設定してください。

    export LD_ASSUME_KERNEL=2.2.5

変動でないスタックの Linux システムでは、-Xss に何が設定されているかに関係なく、 各スレッドごとに最小 256 KB のネイティブ・スタック・サイズが用意されています。浮動スタックの Linux システムでは、-Xss の値が尊重されます。 したがって、変動でないスタックの Linux システムからマイグレーションする場合は、 -Xss の値が十分な大きさで、最小値の 256 KB に依存していないことを 確認してください。

## XML 文書の変換

IBM SDK には、JAXP 1.3 仕様に準拠した XSLT4J プロセッサーと XML4J パーサーが含まれます。 これらのツールでは、XML 処理の実装とは関係なく、 XML 文書を解析および変換することができます。 「ファクトリー・ファインダー」を使用して SAXParserFactory、 DocumentBuilderFactory、および TransformerFactory の実装を見つけることによって、 アプリケーションは、コード変更の必要なく、異なる実装の間でスワップすることができます。

|IBM SDK に組み込まれている XML テクノロジーは、Apache Xerces Java および Apache Xalan Java と類似しています。 |詳しくは、http://xml.apache.org/xerces2-j/ |および http://xml.apache.org/xalan-j/ を参照してください。

XSLT4J プロセッサーでは、元の XSLT Interpretive プロセッサーまたは新しい XSLT Compiling プロセッサーを選択できます。 Interpretive プロセッサーは、ツールおよびデバッグ環境用に設計されたもので、 XSLT Compiling プロセッサーでサポートされない XSLT 拡張機能をサポートします。 XSLT Compiling プロセッサーは、ハイパフォーマンスのランタイム環境用に設計されたもので、 XSL スタイル・シートから変換エンジンであるトランスレット を生成します。 この方法により、ランタイム・アプリケーションから XML データへのスタイル・シート命令の解釈が分離されます。

XSLT Interpretive プロセッサーがデフォルト・プロセッサーです。 XSLT Compiling プロセッサーを選択するには、以下が可能です。

- jaxp.properties ファイル ( /opt/ibm/java2-i386-50/jre/lib 内) の項目を変更します。または
- javax.xml.transform.TransformerFactory キーのシステム・プロパティーを org.apache.xalan.xsltc.trax.TransformerFactoryImpl に設定します。

jaxp.properties ファイルのプロパティーを実装するには、jaxp.properties.sample を /opt/ibm/java2-i386-50/ の jaxp.properties にコピーします。 このファイルには、TransformerFactory、SAXParserFactory、および DocumentBuilderFactory について、使用する実装を判別するための手順に関する全詳細も含まれます。

XSLT Compiling プロセッサーでの StreamSource オブジェクトの変換時にパフォーマンスを向上させるには、 サービス org.apache.xalan.xsltc.dom.XSLTCDTMManager のプロバイダーとして com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager クラスを指定します。 サービス・プロバイダーを判別するには、org.apache.xalan.xsltc.dom.XSLTCDTMManager が見つかるまで、 各ステップを試行してください。

1. システム・プロパティー org.apache.xalan.xsltc.dom.XSLTCDTMManager の設定を確認します。
2. ファイル /opt/ibm/java2-i386-50/lib/xalan.properties のプロパティー org.apache.xalan.xsltc.dom.XSLTCDTMManager の値を確認します。
3. クラス名についてファイル META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager の内容を確認します。
4. デフォルト・サービス・プロバイダー org.apache.xalan.xsltc.dom.XSLTCDTMManager を使用します。

javax.xml.transform.TransformerFactory オブジェクトが作成されると、 XSLT Compiling プロセッサーは、org.apache.xalan.xsltc.dom.XSLTCDTMManager サービスのサービス・プロバイダーを検出します。 その TransformerFactory オブジェクトを使用して作成された javax.xml.transform.Transformer または javax.xml.transform.sax.TransformerHandler オブジェクトはすべて、同じサービス・プロバイダーを使用します。 上記のいずれかの設定を変更して、新しい TransformerFactory オブジェクトを作成することによってのみ、 サービス・プロバイダーを変更できます。

### 旧バージョンの Xerces または Xalan の使用

旧バージョンの Tomcat を使用している場合、次の制限が適用されます。

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

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

- 最新の Java API for XML Programming (JAXP) 仕様 (http://java.sun.com/xml/jaxp/index.html) を 実装しているアプリケーションを新規バージョンにアップグレードします。
- jaxp.properties ファイルを /opt/ibm/java2-i386-50/jre/lib から削除します。
- /opt/ibm/java2-i386-50/jre/lib にある jaxp.properties ファイルの項目のコメントを外します。
- IBM_JAVA_OPTIONS 環境変数を使用して明示的に SAX Parser、DocumentBuilder、あるいは Transformer ファクトリーを設定します。 例えば、次のようにします。

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
        org.apache.xerces.jaxp.SAXParserFactoryImpl

  または

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
        org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

  または

      export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
        org.apache.xalan.processor.TransformerFactoryImpl

- ご使用のアプリケーション・コードの中から、javax.xml.parsers.SAXParserFactory、javax.xml.parsers.DocumentBuilderFactory、 または javax.xml.transform.TransformerFactory のシステム・プロパティーを設定します。 例は、JAXP 1.3 の仕様を参照してください。

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

以下の節では、SDK for Linux を使用した Java アプリケーションの開発について説明します。 使用可能なツールの詳細については、『SDK ツール』を参照してください。

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

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

### 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>
            MyApp <MyApp args>

2. JVM は開始しても、Java アプリケーションを開始させるまでは、実行を中断します。 別のセッションで、デバッガーを JVM に接続できます。

       jdb -attach <port number>

   デバッガーが JVM に接続したら、一連のコマンドを実行して Java アプリケーションを 検査し制御することができます。例えば、`run` と入力して Java アプリケーションを 実行させることができます。

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

    jdb -help

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

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

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

1. 前述のように JVM を開始します。
2. デバッガーをリモート・マシンに接続させます。

       jdb -attach <machine name または ip address>:<port number>

dt_socket トランスポートを使用してデバッグ・セッションを起動するとき、 指定のポートが空いていて使用できることを確認してください。

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

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

- http://java.sun.com/products/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdb.html

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

Java アプリケーションの中には、それが 32 ビット JVM で実行されているか、 64 ビット JVM で実行されているかを判別可能でなければならないものがあります。 例えば、アプリケーションにネイティブ・コード・ライブラリーがある場合、 32 ビットと 64 ビットの両方の稼働モードをサポートするプラットフォーム用に、 そのライブラリーは、32 ビットおよび 64 ビット形式で別々にコンパイルされる必要があります。 この場合、32 ビット・コードと 64 ビット・コードは混用できないため、 アプリケーションが実行時に正しいライブラリーをロードしなければなりません。

システム・プロパティー com.ibm.vm.bitmode を使用して、 アプリケーションは、JVM の稼働モードを判別することができます。 これは、以下の値を戻します。

- 32 - JVM は 32 ビット・モードで稼働
- 64 - JVM は 64 ビット・モードで稼働

アプリケーション・コード内から com.ibm.vm.bitmode を検査するには、次の呼び出しを使用します。

    System.getProperty("com.ibm.vm.bitmode");

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

ネイティブ・プログラムが JNI_CreateJavaVM() API 呼び出しで指定できる有効な JNI バージョン番号は、以下のとおりです。

- JNI_VERSION_1_2(0x00010002)
- JNI_VERSION_1_4(0x00010004)

このバージョン番号で決まるのは、使用する JNI ネイティブ・インターフェースのレベルのみです。 作成される JVM の実際のレベルは、J2SE ライブラリーによって指定されます (つまり、v5.0)。 JNI インターフェース API は、JVM によって実装される言語仕様や、 クラス・ライブラリー API、その他の範囲の JVM 動作に影響しません。 詳しくは、http://java.sun.com/j2se/1.5.0/docs/guide/jni を参照してください。

32 ビット用に作成されたものと 64 ビット用に作成されたものの 2 つの JNI ライブラリーがアプリケーションで必要な場合、 com.ibm.vm.bitmode システム・プロパティーを使用して、 32 ビットまたは 64 ビット JVM のどちらで実行しているかを判別し、適切なライブラリーを選択します。

IBM 5.0 SDK でネイティブ・アプリケーションをコンパイルおよびリンクするには、次のコマンドを使用します。

    gcc -I/opt/ibm/java2-i386-50/include -L/opt/ibm/java2-i386-50/jre/bin/j9vm
    -ljvm -ldl -lpthread <JNI program filename>

-ljvm オプションは、libjvm.so が、JVM を実装する共用ライブラリーであることを指定します。 -lpthread オプションは、ネイティブ pthread サポートを使用することを指示します。pthread ライブラリーとリンクしないと、 JNI プログラムの実行時にセグメンテーション障害 (シグナル SIGSEGV) が発生する可能性があります。

注:
Java Native Interface (JNI) の Version 1.1 はサポートされません。
| | |

## ブロックされたコネクターのスレッド・レベル・リカバリーのサポート

|

ブロックされたコネクターのスレッド・レベル・リカバリーをサポートするために、 |com.ibm.jvm パッケージに IBM 固有の SDK クラスが新規に 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/apidoc.zip に提供されます。

## アプレットの処理

アプレット・ビューアーを使用すれば、Web ページ (HTML ファイル) 内から APPLET タグを使った 参照で呼び出される 1 つ以上のアプレットを実行できます。 アプレット・ビューアーは、HTML ファイルで APPLET タグを見つけると、タグで指定されているとおりに 別のウィンドウでそのアプレットを実行します。

アプレット・ビューアーは、アプレットを表示するためのものなので、HTML タグを数多く含む Web ページ全体は表示できません。 Web ページ上で APPLET タグのみを解析し、他の HTML タグは解析しません。

### アプレット・ビューアーでアプレットを実行する

アプレットをアプレット・ビューアーで実行するには、シェル・プロンプトで次のように入力します。

       appletviewer name

ここで、name には、以下のいずれかを指定します。

- アプレットを呼び出している HTML ファイル名
- アプレットを呼び出している Web ページの URL

例えば、アプレットの呼び出し元の HTML ファイルでアプレット・ビューアーを起動するには、 シェル・プロンプトで次のように 入力します。

      appletviewer $HOME/filename.html

ここで、filename は、HTML ファイルの名前です。

例えば、`http://java.sun.com/applets/NervousText/example1.html` が、アプレットを呼び出している Web ページの URL であるとします。 この Web ページで アプレット・ビューアーを呼び出すには、シェル・プロンプトで次のように入力します。

    appletviewer http://java.sun.com/applets/NervousText/example1.html

アプレット・ビューアーは、<META> タグの charset オプションは認識しません。 アプレット・ビューアーがロードするファイルが、システム・デフォルトとしてエンコードされていないと、 I/O 例外が発生する可能性があります。 この例外を避けるには、アプレット・ビューアーを実行するときに、 -encoding オプションを使用します。 例えば、次のようにします。

    appletviewer -encoding JISAutoDetect sample.html

### アプレット・ビューアーでアプレットをデバッグする

アプレットをデバッグするには、アプレット・ビューアーの -debug オプションを使用します。 アプレットをデバッグするときは、そのアプレットの呼び出し元の HTML ファイルが入っている ディレクトリーからアプレット・ビューアーを呼び出すことをお勧めします。 例えば、次のようにします。

    cd demo/applets/TicTacToe
    ../../bin/appletviewer -debug example1.html

アプレット・ビューアーを使用してアプレットをデバッグする方法についてのドキュメンテーションは、 Sun の Web サイト http://java.sun.com で参照できます。

| | |

## 大規模ページのメモリー割り振りの構成

|

大規模ページをサポートするシステムで大規模ページ・サポートを使用可能にするには、 |-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 2 Platform, Standard Edition (J2SE) は、 J2SE (V1.5) の CORBA サポート公式仕様に定義されている仕様は最小限サポートしています。場合によっては、IBM J2SE ORB で、より新しいバージョンの仕様をサポートしている場合もあります。

### GIOP 1.2 のサポート

この SDK は、OMG 資料「formal/99-10-07」の第 13 章 および 15 章の CORBA 2.3.1 仕様で定義されているように、すべてのバージョンの GIOP を サポートしています。この OMG 資料は、以下のサイトから入手できます。

http://www.omg.org/cgi-bin/doc?formal/99-10-07

双方向 GIOP は、サポートされていません。

### ポータブル・インターセプターのサポート

この SDK は、資料「ptc/01-03-04」で OMG によって定義されているように ポータブル・インターセプターをサポートします。この資料は、以下のサイトから入手できます。

http://www.omg.org/cgi-bin/doc?ptc/01-03-04

ポータブル・インターセプターは、ORB へのフックで、これにより ORB サービスは ORB の通常の実行フローをインターセプトすることができます。

### 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 を指定します。 しかし、このメソッドは Version 5.0 の Sun Java Core API では使用できません。 現行バージョンでサービスの登録が必要なプログラムは、このメソッドを IBM 内部の ORB 実装クラスで呼び出す必要があります。 例えば、サービス「MyService」を登録するには以下のようにします。

    ((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService",
    serviceRef);

ここで、`orb` は、`ORB.init()` から戻される `org.omg.CORBA.ORB` のインスタンスで、 `serviceRef` は、ORB に接続される CORBA オブジェクトです。 この手段は、一時的なもので、今後のバージョンと互換性はなく、また、IBM 以外の ORB にも 移植できません。

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

ランタイム・デバッグ機能により、保守容易度が向上しました。これは、問題診断に有効ですし、 IBM サービス技術員から要求される場合もあります。 トレースは、3 つのシステム・プロパティーで制御されます。

- トレースをオンにするには、`com.ibm.CORBA.Debug=true` を設定してください。
- 送受信された GIOP メッセージをフォーマット設定し、トレースに追加するには、 `com.ibm.CORBA.CommTrace=true` を設定してください。 デフォルトで、ORB トレースは、orbtrc.DDMMYYYY.HHmm.SS.txt という形式の名前を持つファイルに入れられます。
- トレースを別のファイルに送るには、`com.ibm.CORBA.Debug.Output=<filename>` を設定してください。

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

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

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

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

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

以下のプロパティーで、ORB の調整をすることができます。

- GIOP 1.2 のフラグメント化を制御するには、システム・プロパティー com.ibm.CORBA.FragmentSize を設定します。

  例えば、フラグメント・サイズを 4096 バイトに設定するには以下のようにします。

      java -Dcom.ibm.CORBA.FragmentSize=4096 myapp

  デフォルトのフラグメント・サイズは、1024 バイトです。フラグメント・サイズを 0 に設定して フラグメント化をオフにすることができます。

- 異機種混合のネットワークでは、CORBA 要求に対する応答が遅延したり、脱落したりする可能性があります。 システム・プロパティー com.ibm.CORBA.RequestTimeout を使用して、 最大の待ち時間を設定することができます。また、com.ibm.CORBA.LocateRequestTimeout を使用して LocateRequests のタイムアウトを制御できます。 例えば、このどちらの遅延も 30 秒に制限する場合は、以下のように入力します。

      java -Dcom.ibm.CORBA.RequestTimeout=30
           -Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp

  デフォルトで、ORB は、無制限に応答を待ちます。接続の不必要な終了を避けるため、 タイムアウトに低すぎる値を設定しないでください。

- ご使用のプログラムが、ネットワークでサービスを提供しているとき、ORB が 受信要求を読み取る ポートの数を事前割り当ての値に設定しなければならない場合があります。 システム・プロパティー com.ibm.CORBA.ListenerPort を使用してこれを制御することができます。

  例えば、ORB がポート 1050 を使用するように設定する場合は以下のようにします。

      java -Dcom.ibm.CORBA.ListenerPort=1050 myapp

  このプロパティーを設定すると、ORB は、初期化後すぐに listen を開始します。 それ以外の場合は、要求されたときにのみ listen を開始します。

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

Java 2 SecurityManager を使用して実行中に、CORBA API クラスのいくつかのメソッドを呼び出すと、 権限チェックが行われて、その結果 SecurityException になることがあります。 影響のあるメソッドには、以下のものがあります。

表 2. Java 2 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 実装クラスは以下のとおりです。

- org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
- org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton
- javax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpl
- javax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpl
- javax.rmi.CORBA.PortableRemoteObjectClass= com.ibm.rmi.javax.rmi.PortableRemoteObject

これらは、デフォルト値です。これらのプロパティーを設定しないか、または、 実装クラスを直接参照することをお勧めします。移植性を保つためには、実装ではなく、 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-IIOP Programmer's Guide (英語)」は、RMI-IIOP プログラムの作成の概要です。 このガイドは、本資料のインストール時にインストールされています。
- demo ディレクトリーには、以下が含まれます。
  - Java Remote Method Protocol (JRMP) と IIOP プロトコルの間でスイッチ可能な「Hello World」の例 (demo/rmi-iiop/hello)
  - 標準 IDL プログラムと対話する「Hello World」の例 (demo/rmi-iiop/idl)
- 「Java Language to IDL Mapping (英語)」の文書は、 RMI-IIOP の詳細な技術仕様で、以下にあります。
  http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf

## RMI の Connection Handler Pool の実装

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

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

    -Dsun.rmi.transport.tcp.connectionPool=true (あるいは、ヌル以外の任意の値)

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

詳しくは、Sun の Java のサイト http://java.sun.com を参照してください。

## 拡張双方向言語サポート

IBM SDK には、拡張双方向言語サポートが含まれています。 詳しくは、 http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html を参照してください。 双方向言語パッケージの Javadoc は、SDK でファイル docs/apidoc.zip に提供されます。

## 拡張 BigDecimal

| |

Java 5.0 以降、Sun により IBM BigDecimal クラスが java.math.BigDecimal として採用されました。 | IBM は com.ibm.math.BigDecimal の保守を止め、これは推奨されないものとして位置づけています。 | 既存の Java コードをマイグレーションして java.math.BigDecimal を使用することをお勧めします。

|

新しい java.math.BigDecimal は、以前の java.math.BigDecimal と com.ibm.math.BigDecimal |の両方と同じメソッドを使用しています。 java.math.BigDecimal を使用している既存のコードは、そのまま正常に動作します。

|

既存の Java コードを java.math.BigDecimal クラスを使用するようにマイグレーションするには、 |ご使用の java ファイルの先頭にある import ステートメントを、 |`import com.ibm.math.*;` から `import java.math,*;` に変更してください。

## ユーロ記号のサポート

IBM SDK および Runtime Environment は、2002 年 1 月 1 日以降、欧州通貨共同体 (EMU) の国々のデフォルトの通貨 としてユーロを設定しています。

各国の以前の通貨を使用する場合は、Java コマンド行で `-Duser.variant=PREEURO` を指定してください。

英国、デンマーク、あるいはスウェーデンのロケールを使用している場合で、ユーロを使用するには、 Java コマンド行で `-Duser.variant=EURO` を指定してください。

# Java Communications API (JavaComm) の使用

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 Version 5.0 Runtime Environment の入ったシステムに対応しています。

Java Communications API を使用すると、以下のことができます。

- システムのポートをリストする。
- ポートの所有権をオープンし、要求する。
- Java Communications API を使用するアプリケーション間のポート所有権の競合を解決する。
- イベント通知によって非同期および同期入出力ポートのモニタリングを行う。
- ポートの状態変更を記述する bean スタイルのイベントを受信する。

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

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

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

1. root でログオンしていること確認して、シェル・プロンプトをオープンします。
2. `rpm -ivh` コマンドを使用して、Java Communications API RPM ファイルをインストールします。 例えば、次のようにします。

       rpm -ivh ibm-java2-<arch>-javacomm-5.0-0.0.<arch>.rpm

   Java Communications API は、/opt/ibm/java2-i386-50/ ディレクトリー構造内にインストールされます。

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

1. Java Communications API アーカイブ・ファイル ibm-java2-javacomm-50-linux-<arch>.tgz を IBMJava2-50 ディレクトリーが入っているディレクトリーに入れます。
2. シェル・プロンプトから、.tgz ファイルが入っているディレクトリーにコンテンツを解凍します。

       tar -xvzf ibm-java2-javacomm-50-linux-<arch>.tgz

   Java Communications API が既存の IBMJava2-50 ディレクトリー内のサブディレクトリーに 解凍されます。

## Java Communications API ファイルの位置

Java Communications API ファイルが、以下に示すようにインストールされます。

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

デフォルト・ディレクトリーにインストールした場合、comm.jar ファイルは、/opt/ibm/java2-i386-50/jre/lib/ext に入ります。

パッケージを別のディレクトリーにインストールした場合、上記のファイルは同じディレクトリー構造で 配置されますが、/opt/ibm/java2-i386-50/ は、Java Communications API をインストールしたディレクトリーと置き換えられます。

## Java Communications API の構成

Java Communications API をインストール後、以下のことをしてください。

- シリアルおよびパラレル・ポートのアクセス・モードを変更する。
- Java のインストール時に設定していない場合は、PATH の設定をする。『PATH の設定』を参照してください。

### シリアルおよびパラレル・ポートのアクセス・モードを変更する

Java Communications API をインストール後、シリアルおよびパラレル・ポートのアクセス・モードを 変更し、ユーザーがこれらのデバイスにアクセスできるようにします。ユーザーに 必要なデバイスに対する読み取り/書き込みアクセス権限を与える必要があります。root でログオンして、 該当する以下のコマンドを使用してください。

        chmod 666 /dev/ttyS0    (別名 シリアル・ポート COM1)
        chmod 666 /dev/lp0      (別名 パラレル・ポート LPT1)
        chmod 666 /dev/ttyS1    (別名 シリアル・ポート COM2)
        chmod 666 /dev/ttyS2    (別名 シリアル・ポート COM3)
        chmod 666 /dev/ttyS3    (別名 シリアル・ポート COM4)

これらのコマンドは、システム上のすべてのユーザーに読み取り/書き込みアクセス権限を与えます。

代替方法としては、許可を 660 にして、特定のユーザーをデバイスが含まれているグループに 追加する方法があります。 例えば、SUSE システムでは、デバイスは、`uucp` グループにあります。この場合、 ユーザーは `uucp` グループに追加されると、そのデバイスへのアクセス権も得られます。

必要に応じてそのほかのポートのアクセス・モードを変更します。

#### javax.comm.properties ファイルのデバイスを指定する

ファイル javax.comm.properties で、Java Communications API に使用可能にするデバイスの 接頭部と、それらがパラレルかシリアルかを指定することができます。 ポート番号は、すべてのデバイスに順番に割り振られます。 例えば、`/dev/ttyS=PORT_SERIAL` を指定していて、 デバイス `/dev/ttyS0` と `/dev/ttyS1` が存在する場合、 これらは、それぞれ 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 Version の ThinkPad 構成ユーティリティーを使用する必要があります。 ThinkPad 構成ユーティリティーを使用するには、ブート可能な DOS ディスケットが必要です。 ThinkPad 構成ユーティリティーは、インストール・オプションによっては、Windows の 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 -e ibm-java2-<arch>-javacomm-5.0-0.0

   代わりに、kpackage あるいは yast2 などのグラフィック・ツールを使用することもできます。

2. Java Communications API をインストールしたディレクトリーに、必要な他のツールが含まれていない場合は、 PATH ステートメントからそのディレクトリーを削除します。

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

圧縮された TAR パッケージをインストールしている場合に、Java Communications API をアンインストールするには、 TAR パッケージをインストールしたディレクトリーから以下のファイルを削除します。

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

## Java Communications API ドキュメンテーション

API ドキュメンテーションと Java Communications API のサンプルは、次の Sun Web サイト http://java.sun.com で参照できます。

# Java アプリケーションの配置

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

Java Plug-in は Web ブラウザー・プラグインです。 Java Plug-in を使用すると、 アプレットや Bean を Web ブラウザーで実行するために、 Web ブラウザーのデフォルト JVM を迂回して、代わりに、選択した Runtime Environment を使用することができます。

アプレットがロードを完了できるようにして、ブラウザーが「ハング」しないようにしてください。 例えば、「戻る」ボタンを使用してから、 アプレットのロード中に「進む」ボタンを使用すると、HTML ページがロードできない可能性があります。

Java Plug-in に関しては、Sun の http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/ に記述があります。

### サポートされるブラウザー

|Linux PPC32 の場合、Mozilla 1.6 がサポートされるブラウザーです。

|Linux IA32 の場合、表 3 を参照してください。

|表 3. Linux IA32 で Java Plug-in によってサポートされるブラウザー
|ディストリビューション | |Netscape のデフォルト・バージョン | |Netscape のサポート・バージョン | |Mozilla のデフォルト・バージョン | |Mozilla のサポート・バージョン
--- | --- | --- | --- | ---
|Red Hat Enterprise Linux 3.0 | |- | |7.x | |1.4.2 | |1.4.1、1.4.2、1.7.8、Firefox 1.0.x
|Red Hat Enterprise Linux 4.0 | |4.8 | |7.x | |1.7.3 | |1.4.1、1.4.2、1.7.8、Firefox 1.0.x
|SUSE Linux Enterprise Server 9.0 | |- | |7.x | |1.6 | |1.4.1、1.4.2、1.6、1.7.8、Firefox 1.0.x

|

### Java Plug-in のインストールと構成

|複数のバージョンの Java Plug-in が SDK で提供されています。 |ご使用のブラウザーに応じて適切なバージョンを選択します。最も一般的なのは、次のものです。

| |
libjavaplugin_oji.so
|
  最も一般的な Plug-in。Mozilla の Open JVM Integration イニシアチブに基づき、 |Firefox を含む大部分の Mozilla 製品および派生品で使用されています。 |
|
libjavaplugin_ojigtk2.so
|
  上記と同じだが、GTK2 ツールキットでコンパイルされた Plug-in。 |

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

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

#### Mozilla

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

Java Plug-in をすべてのユーザーが使用できるようにするには:

1. root としてログインします。
2. Mozilla Plug-in のディレクトリー (これは、Linux ディストリビューションによっては異なる場合があります) に移動します。

       cd /usr/local/mozilla/plugins/

3. |libjavaplugin_oji.so に対するシンボリック・リンクを作成します。 | |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

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

| | |

#### Firefox

|

Java Plug-in をすべてのユーザーが使用できるようにするには: |

|

|
1. root としてログインします。
|
2. Firefox の Plug-in ディレクトリー (これは、Linux ディストリビューションによっては異なる場合があります) |に移動します。 | |

       cd /usr/local/mozilla-firefox/plugins/

|
3. |libjavaplugin_oji.so に対するシンボリック・リンクを作成します。 | |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

   |

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

#### Netscape 7.1 以上

Netscape 用に Java Plug-in をインストールして構成するには、 ライブラリー・ファイル /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so からブラウザーの Plug-in ディレクトリー (/browser-install-path/plugins) へのシンボリック・リンクを作成します。

1. root としてログインします。
2. Netscape の Plug-in ディレクトリー (これは、Linux ディストリビューションによっては異なる場合があります) に移動します。

       cd /usr/local/netscape/plugins/

3. javaplugin_oji.so へのシンボリック・リンクをその Plug-in ディレクトリーに作成します。

       ln -s /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so .

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

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

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

- これらの機能の一部については sun.plugin.dom.exception.NotSupportedException がスローされます。
- ブラウザーが特定の機能をサポートしていないときには、sun.plugin.dom.exception.InvalidStateException がスローされます。

### 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 ファイルを解析するように指示するものです。すべてのパラメーターが正しく Java Plug-in に渡されます。 しかし、一部の古いバージョンのブラウザーでは、このタグが正しく認識されないことがあります。その場合には、ブラウザーにこのタグを無視するように強制できますが、エンコードを手動で変更しなければならないこともあります。

次のようにして、HTML ファイルの解析に使用するエンコード方式を指定することができます。

- Netscape 4: 「表示」メニュー ->「文字セット」
- Mozilla: 「表示」メニュー ->「文字コード」

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

Java アプリケーションを配置するために Java Web Start を使用できます。 Web Start によって ユーザーは、Web から直接アプリケーションを起動し、管理することができます。 Java Web Start を使用すれば、Web で簡単にアプリケーションを開始することができます。その際、 確実に最新バージョンを稼働することができ、インストールやアップグレードの手間も省けます。 Java Web Start により、ソフトウェアのダウンロードやインストールの必要もなくなり、時間のかかる インストール・オプションの設定も回避できます。

|http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources に文書化されている java-vm-args のほかに、Web Start は、ガーベッジ・コレクション・ポリシーを設定する |-Xgcpolicy をサポートします。

Web Start をサポートするブラウザーについて詳しくは、『サポートされるブラウザー』を参照してください。

Web Start についての詳細は、http://java.sun.com/products/javawebstart および http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html を参照してください。 アプリケーションの配置についての詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html を参照してください。

### Web Start の実行

Java Web Start v5.0 は、.rpm または .tgz パッケージによる Java のインストール時に、 自動的にインストールされます。

|Java を .tgz パッケージから抽出した場合、jre/lib/javaws/updateSettings.sh |シェル・スクリプトを実行して、システムの .mailcap および .mime.types ファイルを更新してください。

Web Start は、以下の 3 つの方法で起動できます。

1. .jnlp ファイルを参照する、Web ページ上のリンクを選択します。
2. シェル・プロンプトで、 `javaws <URL>` と入力します。ここで、`<URL>` は .jnlp ファイルの位置です。
3. |既に Java Web Start を使用してアプリケーションをオープンしている場合は、 |jre/bin ディレクトリーから |javaws を実行し、Java アプリケーション・キャッシュ・ビューアーを起動します。

アプリケーションは、ダウンロードされると、Java アプリケーション・キャッシュに保管されます。 そのアプリケーションが再アクセスされたときに、Java Web Start は、 アプリケーションの最新のバージョンがあればダウンロードし、 なければキャッシュ内のものを使用します。

.jnlp ファイルでエラーが発生すると (無効なタグ名など)、Web Start はエラー・メッセージを表示せずに失敗します。

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

Java アプレットと異なり、Java アプリケーションは、インストールおよびランタイム・サービスについて Web ブラウザーに依存することができません。 Java アプリケーションを出荷する場合、 ソフトウェア・パッケージは、多くの場合、以下のパーツから構成されます。

- 独自のクラス、リソース、およびデータ・ファイル
- インストール手順またはインストール・プログラム

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

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

| | |

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

|

IBM Virtual Machine (VM) では、共用メモリーのキャッシュに保管することによって、 |VM 間でブートストラップおよびアプリケーション・クラスを共用することができます。 |複数の VM がキャッシュを共用する場合、クラス共用で全体の仮想メモリー使用量が削減されます。 |また、クラス共用によって、キャッシュ作成後の VM の起動時間も短縮されます。 |共用クラス・キャッシュは、どのアクティブ VM からも独立したもので、 |キャッシュを開始した VM の存続期間を超えて存続します。

| |

## クラス共用の概要

|

IBM SDK では、可能な限り多くのクラスを共用でき、 |一方、ユーザーはそれを意識しません。

| |

### キャッシュの内容

|

共用クラス・キャッシュには、読み取り専用の静的クラス・データと、クラスを記述するメタデータが含まれます。 |任意の VM が、キャッシュの読み取りや更新を行えます。共用している VM は、同じリリースでなければなりません。 |実行時バイトコード変更を使用する場合は、注意が必要です。 |(『実行時バイトコード変更』を参照)

| |

### キャッシュの動的更新

|

共用クラス・キャッシュは任意の VM の存続期間を超えて存続するため、 |ファイル・システムで JAR やクラスに行われた可能性がある変更を反映するよう、 |キャッシュは動的に更新されます。動的更新により、キャッシュを使用するアプリケーションでキャッシュを意識する必要がなくなります。

| |

### クラス共用の使用可能化

|

VM の始動時に -Xshareclasses オプションを使用してクラス共用を使用可能にすると、 |VM を既存のキャッシュに接続させるか、それが存在しない場合には作成します。 |VM によってロードされるすべてのブートストラップおよびアプリケーション・クラスが、 |デフォルトで共用されます。カスタム・クラス・ローダーは、アプリケーション・クラス・ローダーを継承している場合、 |自動的に共用します。それ以外の場合は、VM で提供される Java ヘルパー API |を使用してそのキャッシュにアクセスする必要があります。(『カスタム・クラス・ローダーの共用クラスへの適応』を参照)

| |

### キャッシュ・セキュリティー

|

共用クラス・キャッシュへのアクセスは、オペレーティング・システムの許可と |Java セキュリティーの許可によって制限されます。 |共用クラス・キャッシュは、 |groupAccess コマンド行サブオプションが使用された場合を除いて、 |デフォルトでユーザー・アクセスで作成されます。クラスの共用を登録したクラス・ローダーのみが、共用クラス・キャッシュにクラスを追加できます。 |Java SecurityManager がインストールされている場合、 |デフォルト・ブートストラップ、アプリケーション、および拡張クラス・ローダーを除いて、 |クラス・ローダーには、クラス SharedClassPermission を java.policy ファイルに追加することによって、 |クラス共用の許可を付与する必要があります。(『SharedClassPermission の使用』を参照) |RuntimePermission 「createClassLoader」は、新しいクラス・ローダーの作成を制限し、 |したがって、キャッシュへのアクセスも制限します。

| |

### キャッシュの存続期間

|

1 つのシステムに複数のキャッシュが存在することが可能で、それらは、 |-Xshareclasses コマンドのサブオプションとして名前で指定されます。 |1 つの VM は、常に 1 つのキャッシュにのみ接続できます。 |キャッシュ・サイズは、始動時に -Xscmx<n>[k|m|g] で指定し、その後、 |キャッシュの存続期間中このサイズは変わりません。 |キャッシュは、-Xshareclasses コマンドのサブオプションを使用して明示的に破棄されるか、 |システムがリブートされるまで存在します。

| |

### キャッシュ・ユーティリティー

|

キャッシュ・ユーティリティーはすべて、-Xshareclasses コマンドのサブオプションです。 |-Xshareclasses:help で、使用可能なサブオプションのリストが表示されます。

| |

## クラス共用のためのコマンド行オプションの使用

|

クラス共用は、-Xshareclasses および -Xscmx コマンド行オプションにより使用可能にし、構成します。

|

|
- -Xscmx<size>[k|m|g] | |
  |
  - キャッシュ・サイズを指定します。 |このオプションは、キャッシュを作成中で、同じ名前の既存のキャッシュがない場合にのみ適用されます。 |デフォルト・キャッシュ・サイズは、プラットフォームによって異なります。 |使用されるサイズ値を知るには、コマンド行引数として -verbose:sizes を追加します。最小キャッシュ・サイズは 4 KB です。 |最大キャッシュ・サイズも、プラットフォームによって異なります。 |(『キャッシュ・サイズの制限』を参照)
|
- -Xshareclasses:<suboption1>[,<suboption2>...] | |
  |
  - クラス共用を使用可能にします。多くのサブオプションを指定でき、その中に複数のキャッシュ・ユーティリティーが含まれます。 |キャッシュ・ユーティリティーは、VM を始動せずに、指定されたキャッシュに必要な操作を実行します。 |複数のサブオプションをコンマで区切って組み合わせられますが、 |各キャッシュ・ユーティリティーは相互に排他的です。
  |-Xshareclasses オプションで以下のサブオプションを使用できます。 |例えば、-Xshareclasses:help のようにします。 | |
  |
  - help | |
    |
    - すべてのコマンド行オプションをリストします。
  |
  - name=<name> | |
    |
    - 指定された名前のキャッシュに接続します。そのキャッシュが存在しない場合は、それを作成します。 |listAllCaches ユーティリティー・オプションで、 |現在使用可能なキャッシュが示されます。名前を指定しないと、 |デフォルト名「sharedcc_」に現行ユーザー名が付加されてキャッシュ名が生成されます。
  |
  - groupAccess | |
    |
    - 新しいキャッシュにオペレーティング・システムの許可を設定し、 |キャッシュへのグループ・アクセスを可能にします。デフォルトは、ユーザー・アクセスのみです。
  |
  - verbose | |
    |
    - verbose を指定すると、キャッシュ入出力アクティビティーに関する詳細出力が生成され、 |保管および検出されたクラスに関する情報がリストされます。 |クラス・ローダーには、固有 ID (ブートストラップ・ローダーは常に 0) |が与えられ、出力には現在有効なクラス・ローダー階層が示されます。各クラス・ローダーは、 |この階層において、それぞれの親にクラスを要求しないと、ロードすることができません。 |失敗した要求が多く見られるのが通常です。この動きは、クラス・ローダー階層で予想されるものです。 |クラス共用が使用可能の場合、標準オプション -verbose:class |でもクラス共用の詳細出力を使用可能にします。
  |
  - modified=<modified context> | |
    |
    - このオプションは、 |実行時にバイトコードを変更する可能性があるバイトコード・エージェントがインストールされている場合に必要です。 |このオプションを指定せず、バイトコード・エージェントがインストールされている場合、 |キャッシュで保管または検出されるクラスはありません。 |<modified context> は、ユーザーが選択した記述子で、例えば、 |「myModification1」などです。これは、コンテキスト myModification1 を使用する JVM のみが同じクラスを共用するように、 |キャッシュを分割します。 |例えば、ある変更コンテキストで「HelloWorld」を実行し、その後、別の変更コンテキストでそれを再実行した場合、 |キャッシュにすべてのクラスが 2 回保管されます。
  |
  - destroy (ユーティリティー・オプション) | |
    |
    - name=<name> |サブオプションで指定された名前を使用するキャッシュを破棄します。 |名前が指定されない場合、デフォルト・キャッシュが破棄されます。 |キャッシュは、それを使用するすべての VM がシャットダウン済みで、ユーザーに十分な許可がある場合にのみ、破棄可能です。
  |
  - destroyAll (ユーティリティー・オプション) | |
    |
    - ユーザーに使用可能なすべてのキャッシュの破棄を試行します。 |キャッシュは、それを使用するすべての VM がシャットダウン済みで、ユーザーに十分な許可がある場合にのみ、破棄可能です。
  |
  - expire=<time in minutes> |(ユーティリティー・オプション) | |
    |
    - 指定された期間に使用されなかったすべてのキャッシュを破棄します。
  |
  - listAllCaches (ユーティリティー・オプション) | |
    |
    - システム上のすべてのキャッシュをリストし、それが使用中であるか、および最後にいつ使用されたかを示します。
  |
  - printStats (ユーティリティー・オプション) | |
    |
    - name=<name> サブオプションで指定されたキャッシュに関する |要約統計情報を表示します。 |名前が指定されない場合、デフォルト・キャッシュに関する統計が表示されます。 |表示される最も有用な情報は、 |キャッシュがどのぐらい満杯であるか、また、それにいくつのクラスが含まれるかです。 |「stale」クラスとは、ファイル・システム上で更新され、そのためキャッシュが「stale」とマーク付けしたクラスです。 |stale クラスは、キャッシュからパージされません。 |詳しくは、「Diagnostics Guide (英語)」を参照してください。
  |
  - printAllStats (ユーティリティー・オプション) | |
    |
    - name=<name> サブオプションで指定されたキャッシュの内容に関する |詳細情報を表示します。 |名前が指定されない場合、デフォルト・キャッシュに関する統計が表示されます。 |すべてのクラスは、ロード元の位置への参照とともに発生順にリストされます。 |詳しくは、「Diagnostics Guide (英語)」を参照してください。

| |

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

|

クラス共用を使用可能にするには、アプリケーション・コマンド行に |-Xshareclasses[:name=<name>] を追加します。 |VM は、指定された名前の既存キャッシュに接続するか、その名前の新しいキャッシュを作成します。 |新しいキャッシュが作成された場合、キャッシュが満杯になるまで、 |ロードされるすべてのブートストラップおよびアプリケーション・クラスがそれに取り込まれます。 |2 つ以上の VM が同時に始動された場合、 |それらすべてが同時にキャッシュにデータの取り込みをします。

|

キャッシュが作成されたことを確認するには、`java -Xshareclasses:listAllCaches` を実行します。 |共用されるクラス数とクラス・データ量を確認するには、`java -Xshareclasses:[name=<name>],printStats` を実行します。 |(このユーティリティーは、アプリケーション VM の終了後か、別のコマンド・ウィンドウで実行できます)

|

キャッシュからロードされる、またはキャッシュに保管されるクラスを確認するには、 |アプリケーション・コマンド行に `-Xshareclasses:[name=<name>],verbose` を追加します。

|

作成されたキャッシュを削除するには、`java -Xshareclasses:[name=<name>],delete` を実行します。 |キャッシュに多くの stale クラスが含まれるか、キャッシュが満杯で、より大きいキャッシュを作成したい場合にのみ、 |キャッシュを削除する必要があります。

|

キャッシュ・サイズは、個別のアプリケーションに応じて調整することが推奨されます。 |これは、デフォルトが最適サイズである可能性が低いためです。 |最適なキャッシュ・サイズを判別する最も良い方法は、 |大容量のキャッシュを指定 (-Xscmx を使用) してアプリケーションを実行し、 |どのぐらいのクラス・データが保管されたかを printStats で判別することです。 |printStats で示された値に、予備のために少量を加算します。 |クラスは、VM 存続期間中のどの時点でもロードされる可能性があるため、 |この分析はアプリケーションの終了後に行うのが最適です。 |ただし、キャッシュが満杯であることが、それに接続された VM のパフォーマンスや機能に悪影響を与えることはありません。 |そのため、キャッシュ・サイズを必要より小さくすることは、非常に合理的です。

|

キャッシュが満杯になると、そのキャッシュを使用しているすべての VM のコマンド行に、メッセージが出力され、 |それ以降のクラスは、その VM 自身のプロセス・メモリーにロードされます。 |満杯のキャッシュ内のクラスは、依然として共用可能ですが、 |満杯のキャッシュは読み取り専用で、新しいクラスで更新することはできません。

| |

## パフォーマンスとメモリー使用量

|

クラス共用は、類似したコードを実行する複数の VM を使用するシステムで特に有用です。 |そうしたシステムは、仮想メモリー使用量を削減することができます。 |また、VM の始動とシャットダウンを頻繁に行うシステムでも有用で、起動時間を改善することができます。

|

新しいキャッシュの作成とデータ取り込みのオーバーヘッドは、わずかです。 |1 つの VM に対する VM 起動時間は通常、ロードされるクラスの数に応じて、クラス共用を使用していないシステムと比べて 0 から 5 % 抑えられます。 |データ取り込み済みのキャッシュを使用すると、VM 起動時間は通常、 |オペレーティング・システムとロードされるクラスの数に応じて、クラス共用を使用していないシステムと比べて 10 % から 40 % 向上します。 |複数の VM が並行して稼働する場合、全体の起動時間がさらに大きく向上します。

|

クラス共用によりアプリケーションを実行する場合、オペレーティング・システム・ツールを使用して、 |仮想メモリー使用量の削減を確認することができます。

| |

## クラス共用の使用の制限と考慮事項

| |

### キャッシュ・サイズの制限

|

クラスを共用するためのキャッシュは、System V IPC 共用メモリー・メカニズムを使用して割り振られます。

|

理論上の最大キャッシュ・サイズは 2 GB です。指定できるキャッシュのサイズは、 |システムに使用可能な物理スペースおよびページング・スペースの量によって制限されます。

|

プロセスの仮想アドレス・スペースは、 |共用クラス・キャッシュと Java ヒープで共用されるため、 |Java ヒープの最大サイズを増やすと、作成可能な共用クラス・キャッシュのサイズが減ります。

|

キャッシュ・サイズは、SHMMAX の設定により制限されます。 |これは、割り振り可能な共用メモリーの量を制限します。 |これらの設定は、/proc/sys/kernel/shmmax ファイルにあります。SHMMAX は通常 30 MB に設定されます。

| |

### 実行時バイトコード変更

|

バイトコードの変更が可能な JVMTI エージェントを使用する VM は、 |modified=<modified_context> サブオプションがコマンド行で使用されていない限り、クラスを共用できません (前述)。 |modified context (変更コンテキスト) は、実行される変更のタイプを記述する、ユーザー指定の記述子です。 |指定された変更コンテキストを使用するすべての VM は、 |キャッシュに保管された変更クラスが、別の VM によってロードされたときに、期待どおりに変更されるように、 |各クラスに対して予測可能で反復可能な方法でバイトコードを変更する必要があります。 |変更が予測可能でなければならない理由は、共用クラス・キャッシュからロードされたクラスを |エージェントがもう一度再変更することができないためです。 |変更されたバイトコードと変更されていないバイトコードを同じキャッシュに保管することができます。 |このトピックについて詳しくは、「Diagnostics Guide (英語)」を参照してください。

| |

### オペレーティング・システムの制限

|

32 ビット・アプリケーションと |64 ビット・アプリケーションの両方を実行できるオペレーティング・システムの場合、 |32 ビット VM と 64 ビット VM の間でクラス共用は許されません。 |listAllCaches サブオプションでは、使用される VM のアドレス・モードに応じて、 |32 ビットまたは 64 ビットのキャッシュがリストされます。

|

共用クラス・キャッシュは、 |システムに存在するキャッシュに関する識別情報を保管するためのディスク・スペースを必要とします。 |この情報は、/tmp/javasharedresources に保管されます。 |識別情報ディレクトリーが削除された場合、 |VM はシステム上の共用クラスを識別できず、キャッシュを再作成する必要があります。 |`ipcs` コマンドを使用すると、 |VM またはアプリケーションによって使用されているメモリー・セグメントが表示されます。

|

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

| |

### SharedClassPermission の使用

|

クラス共用と併せて SecurityManager が使用され、 |実行アプリケーションがそれ自身のクラス・ローダーを使用する場合、 |クラスを共用するにはその前に、これらのクラス・ローダーにクラス共用の許可が付与されていなければなりません。 |クラス・ローダーのクラス名 (ワイルドカードを使用可) と、付与されるアクセス権を決める "read"、"write"、または "read,write" |のいずれかを指定して、java.policy ファイルに SharedClassPermission を追加します。 |例えば、次のようにします。 |

|

    permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";

クラス・ローダーに適切な SharedClassPermission がなく、それがクラスを共用しようとすると、 |AccessControlException がスローされます。 |デフォルトのブートストラップ、アプリケーション、または拡張クラス・ローダーの許可は、 |変更または削減できません。

| |

## カスタム・クラス・ローダーの共用クラスへの適応

|

ほとんどの Java アプリケーションは、VM 独自のクラス・ローダーを使用するか、 |java/net/URLClassLoader を継承するカスタム・クラス・ローダーを持ちます。 |これらのクラス・ローダーを使用するアプリケーションは、 |ブートストラップおよびアプリケーション・クラスを自動的に共用することができます。 |java/net/URLClassLoader を継承しないカスタム・クラス・ローダーには、 |クラス共用を利用するための変更が必要になります。 |SecurityManager が使用される場合、すべてのカスタム・クラス・ローダーに、クラス共用の許可が付与される必要があります。『SharedClassPermission の使用』を参照してください。 |IBM は、カスタム・クラス・ローダーのさまざまなタイプに応じたいくつかの Java インターフェースを提供しています。 |これにより、そのクラス・ローダーが、共用クラス・キャッシュでクラスを検出および保管することができます。 |これらのクラスは、com.ibm.oti.shared パッケージにあります。 |このパッケージの Javadoc は、SDK でファイル docs/apidoc.zip に提供されます。 |これらのインターフェースの使用方法について詳しくは、 |「Diagnostics Guide (英語)」を参照してください。

# 独立ソフトウェア販売会社のサービスおよびサポート

IBM Solutions Developer Program に準ずるプログラム・コードのサービスを受けられる場合、 通常の利用方法によって、または Web (http://www-1.ibm.com/partnerworld/) で IBM Solutions Developer Program にお問い合わせください。

サービス契約 (つまり、IBM の Personal Systems Support Line または各国における同等サービス) を購入している場合は、 そのサービス契約の条件によって、そのプログラムに関して受けられるサービス (該当がある場合) が決まります。

# アクセシビリティ

この SDK および Runtime Environment で提供されるこのユーザー・ガイドは、スクリーン・リーダーを使用して テストしてあります。 このユーザー・ガイドは、ホームページ・リーダーあるいは JAWS スクリーン・リーダーなどの スクリーン・リーダーを使用することができます。

ユーザー・ガイドのフォント・サイズを変更するには、ご使用のブラウザーで提供される機能を使用して ください。通常、「表示」メニュー・オプションにあります。

キーボード・ナビゲーションが必要なユーザーの場合、Swing アプリケーション用の便利なキー・ストロークの説明が http://www-128.ibm.com/developerworks/java/jdk/additional/ の「Swing Key Bindings」にあります。

## iKeyman のアクセシビリティ

|GUI に加えて、iKeyman ツールには、コマンド行ツールの |IKEYCMD があり、これには、iKeyman GUI と同じ機能があります。 |IKEYCMD では、鍵、証明書、および認証要求を管理することができます。 |IKEYCMD は、アプリケーションで証明書や鍵の管理タスクにカスタム・インターフェースを追加する必要が |ある場合に使用するプログラムおよびネイティブ・シェル・スクリプトから呼び出すことができます。 IKEYCMD は、iKeyman で現在サポートするすべての型の |鍵データベース・ファイルを作成できます。 また、IKEYCMD は、認証要求を作成したり、CA 署名証明書をインポートしたり、 |さらに自己署名証明書を管理したりすることもできます。

IKEYCMD コマンドを実行するには、以下のように入力してください。

    java [-Dikeycmd.properties=<properties file>] com.ibm.gsk.ikeyman.ikeycmd
    <object> <action> [options]

ここで、

<object>
  以下のいずれかです。
  -keydb
    鍵データベース (CMS 鍵データベース・ファイル、WebDB 鍵リング・ファイル、または SSLight クラスのいずれか) に 対して行われるアクション
  -cert
    鍵データベース内の証明書に対して行われるアクション
  -certreq
    鍵データベース内の認証要求に対して行われるアクション
  -version
    IKEYCMD のバージョン情報を表示します。
  -help
    IKEYCMD の呼び出しに関するヘルプを表示します。
<action>
  |オブジェクトに対して行われる特定のアクション。 |オブジェクトに対して使用可能なアクションを表示するには、 |引数としてオブジェクトのみを渡して IKEYCMD を起動します。 |コンテキスト・ヘルプが表示されて、そのオブジェクトに使用可能なアクションを示します。
-Dikeycmd.properties
  この Java の呼び出しに使用するオプションのプロパティー・ファイルの名前を指定します。 デフォルトのプロパティー・ファイルの ikeycmd.properties がサンプル・ファイルとして 提供されていますが、これを変更して、Java アプリケーションで使用することができます。

注:
オブジェクトおよびアクションのキーワードは、 指定された順序にする必要があります。 ただし、オプションは、オペランドとの対で指定するのであれば、定位置にある 必要はなく、任意の順序でかまいません。

詳しくは、http://www.ibm.com/developerworks/java/jdk/security/index.html の「iKeyman User Guide (英語)」を参照してください。

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

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

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

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

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

# 既知の制限

以下の節では、SDK and Runtime Environment for Linux の既知の制約事項について説明します。

## 特に指示がない限りすべての Linux プラットフォームに適用される制限

- |ウィンドウ・マネージャーが、一部の Java キーボード・ショートカットをオーバーライドすることがあります。 |オーバーライドされた Java キーボード・ショートカットの使用が必要な場合は、 |オペレーティング・システムのマニュアルを参照して、 |ウィンドウ・マネージャーのキーボード・ショートカットを変更してください。 | |

- |X Windows System は、255 より上のファイル記述子を使用できません。 |JVM はオープンしている JAR ファイルのファイル記述子を占有するため、X でファイル記述子が不足する可能性があります。 |次善策としては、JAVA_HIGH_ZIPFDS 環境変数を設定して、 |JAR ファイル用に上位のファイル記述子を使用するよう、JVM に指示することができます。 | |

  JAVA_HIGH_ZIPFDS 環境変数を使用する場合、それに 0 から 512 までの値を設定します。 |JVM は、最初の JAR ファイルを最大 1024 のファイル記述子を使用してオープンします。 |例えば、プログラムでおそらく 300 個の JAR ファイルをロードする場合は、次のようにします。

  |`export JAVA_HIGH_ZIPFDS=300` | |

  最初の 300 個の JAR ファイルは、ファイル記述子 724 から 1023 を使用してロードされます。 |その後にオープンされる JAR ファイルは、通常の範囲でオープンされます。

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

- RHEL3、SLES9、および新しいディストリビューションで、デフォルトのスレッド・ライブラリーは、 Java スレッドをネイティブ・スレッドとして実装する NPTL です。 以前のバージョンでは、デフォルトのスレッド・ライブラリーは、スレッドを新しいプロセスとして実装する LinuxThreads です。 Java スレッドの数が許容される最大プロセス数を超えると、プログラムがハングすることがあります。

  使用可能な最大スレッド数は、次の中の最も小さい値で決まります。

  - /etc/security/limits.conf のユーザー・プロセス数設定値 (ulimit -u)
  - /proc/sys/kernel/threads_max に定義されている限度
  - libpthreads.so で定義されている制限 PTHREAD_THREADS_MAX (この値の変更には、glibc の再コンパイルが必要)

  ただし、最大スレッド数に達する前に仮想記憶域を使い尽くしてしまうこともあります。

- Ctrl-C を使用して Java アプリケーションを終了すると、 いくつかのプロセスが孤立したまま残されることがあります。

- ALT キーが含まれる KeyEvent の処理結果は、Linux で使用するウィンドウ・マネージャーによって異なります。 また、他のオペレーティング・システムの結果とも異なります。 Enlightenment ウィンドウ・マネージャーでは、 Alt+A キーおよび Shift+Alt+A キーはそれぞれ異なる修飾子を作成し、 Ctrl+Alt+ A キーはまったくキー・イベントを作成しません。 ただし、WindowMaker ウィンドウ・マネージャーを使用すると、Ctrl+Alt+A でキー・イベントが作成されます。

- Linux X Window System では、キー・マップは 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-Window アプリケーションが除去対象の Meta キーを使用している場合に影響を受けることがあります。

- 一般的でない長さの DSA 鍵ペアの作成は、低速なマシンでは非常に長い時間を要します。 時間の余裕が十分にある場合には、 遅延をハングとして解釈せずに、プロセスが完了するまで待ってください。 DSA 鍵生成アルゴリズムは、標準の鍵の長さ (例えば、512、1024) を他より迅速に生成するよう、最適化されています。

- ネイティブ・プログラムは、 JNI_VERSION_1_1(0x00010001) インターフェースで VM を作成することができません。 JNI_CreateJavaVM() を呼び出して、それに JNI_VERSION_1_1(0x00010001) のバージョンを渡すことはできません。 渡すことができるバージョンは次のとおりです。
  - JNI_VERSION_1_2(0x00010002)
  - JNI_VERSION_1_4(0x00010004)

  作成される VM を決めるのは、存在する Java ライブラリー (つまり、 1.2.2、1.3.x、1.4.x、5.x) であって、渡される JNI インターフェース・バージョンで暗黙指定されたものではありません。

  インターフェース・バージョンは、ネイティブ・コードに使用可能な機能以外の、 どの領域の VM 動作にも影響しません。

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

- 中国語 (繁体字) のユーザーの場合のみ、中国語 (繁体字) 文字の 入力に LinYi ZhuYin、YiTian ZhuYin、および Bosham IME を使用すると、 ファンクション・キーの Enter、スペース、Backspace、および ESC が期待通りに機能しません。 Enter キーは改行を挿入し、ESC キーは事前編集ストリングや候補ウィンドウを取り消すために使用され、スペース・バーはスペースを挿入します。 中国語 (繁体字) の入力に LinYi ZhuYin、YiTian ZhuYin、 および Bosham IME を使用しているときにコミット・キーを押すと候補ウィンドウが消えて、Backspace キーを押しても表示されません。

- 多くの並行スレッドを実行している場合、警告メッセージ `java.lang.OutOfMemoryError` が出されることがあります。 これは、マシンのシステム・リソースが使い尽くされていることを示しており、メッセージは以下の理由によって発生する可能性があります。
  1. 以下の理由で、新規スレッドを作成できない。
     - 作成されたプロセスの数がユーザー制限を超えている。(ご使用の Linux インストール済み環境が、NPTL でなく LinuxThreads を使用している場合。)
     - 新規スレッドを作成するために使用可能な十分なシステム・リソースがない。 この場合、実行中のアプリケーションによっては、他の Java 例外も表示される可能性があります。
  2. カーネル・メモリーが使い尽くされたか、またはフラグメント化している。 強制終了されたプロセス ID に対応する、メモリー不足を示すカーネル・メッセージを /var/log/messages で確認してください。
  システムをチューニングして、対応するシステム・リソースを増やしてください。

- Red Hat が配布したこの製品の前のバージョンがインストールされていると、インストール中に Red Hat Package Manager (RPM) が IBM パッケージが Red Hat が配布した製品のバージョンよりも古いと報告します。 この状態が生じるのは、Red Hat が「シリアル番号」を RPM パッケージに追加し、これがパッケージ中の製品バージョン管理方式をオーバーライドして、 デフォルトでは、RPM がすでにインストールされている製品より古いと見なされるパッケージのインストールを拒否するからです。 rpm コマンドの --oldpackage オプションによって、新規の IBM パッケージをインストールすることができます。

- Java AWT/Swing アプリケーションを Linux マシンで実行し、 その表示を 2 番目のマシンにエクスポートするときに、X クライアント・マシンに ロードしたフォントのセットが X サーバー・マシンにロードしたフォントのセットと異なる場合、 一部のダイアログの表示で問題が発生する可能性があります。 この問題は、特に、サーバー・バージョンのデフォルトのインストールでは 英字フォントがインストールされるが、クライアントのデフォルトのインストールでは インストールされない中国語のロケールの SLES8 で顕著です。 この問題を回避するには、両方のマシンに同じフォントをインストールします。

- システム・ロケールが UTF-8 エンコード方式を使用している場合、 一部の SDK ツールで sun.io.MalformedInputException がスローされる場合があります。 システムが UTF-8 エンコード方式を使用しているかどうかを 確認するには、LANG または LC_ALL などの ロケール固有の環境変数を調べて、その末尾が接尾部「.UTF-8」になっているか確認します。 この sun.io.MalformedInputException が出されたら、7 ビット ASCII の範囲 (0x00 - 0x7f) 外に あり Java Unicode 文字リテラルとして表現されていない文字を Java Unicode 文字リテラル (たとえば「¥u0080」) に変更します。 また、ロケール固有の環境変数から「.UTF-8」接尾部を除去することによっても、 この問題を回避することができます。 たとえば、ご使用のマシンのデフォルトのロケールが 「en_US.UTF-8」である場合は、LANG を「en_US」に設定します。
  注:
  Red Hat 9 や RHEL3 などの一部の Red Hat のディストリビューションでは、 デフォルトで UTF-8 エンコード方式を使用します。

- クロスプラットフォーム環境で AMI および xcin を 使用している場合 (たとえば、32 ビット・システムと 64 ビット・システム間、 またはビッグ・エンディアン・システムとリトル・エンディアン・システム間で 表示をエクスポートしようとする場合) に、問題が発生する可能性があります。 この種の問題が発生したら、Linux のディストリビューターにお問い合わせください。

- Red Hat Enterprise Linux 3 では、中国語 GB18030 ロケールの GB2312 文字を除いて、 中国語の文字が AWT テキスト・コンポーネントで表示されない場合があります。

- |IBM の JConsole ツールで、 |同じシステム上の他の仮想マシンに接続できるようにする「ローカル (Local)」タブが使用できません。 |代わりに、JConsole の「リモート (Remote)」タブを使用して、 |モニターする仮想マシンに接続します。 |モニターするアプリケーションを起動する際、以下のコマンド行オプションを設定してください。 | |
  |
  - 管理エージェントが listen するポートを指定する -Dcom.sun.management.jmxremote.port=<value>
  |
  - ユーザー名ファイルを作成していない場合に認証を使用不可にする -Dcom.sun.management.jmxremote.authenticate=false
  |
  - SSL 暗号化を使用不可にする -Dcom.sun.management.jmxremote.ssl=false
  |

- |Red Hat Enterprise Linux 4 の中国語、韓国語、および日本語ユーザーについてのみ、 |Internet/Intranet Input Method Framework (IIIMF) を使用する場合には、Red Hat Enterprise |Linux 4 Update 2 以降に含まれる IIIMF パッケージを使用してください。 |また、以下の問題に注意してください。この問題が発生した場合には、 |Red Hat の指示を http://www.redhat.com で参照してください。 | |
  |
  - Linux zSeries 64 ビットで、IIIMF の障害が発生したり、起動に障害が起こることがあります。 |日本語ユーザーの場合にのみ、Red Hat Bugzilla 番号 RIT73533 を参照してください。
  | |

- |Red Hat Enterprise Linux 4 の中国語 (簡体字) ユーザーの場合のみ。 |zh_CN.GB18030 のロケールが RHEL4 の xlib でサポートされません。 |xterm は、GB18030 文字を入力するインプット・メソッドをアクティブにできません。 |代わりに、zh_CN.UTF8 のロケールを使用してください。 |GB2312、GBK、または GB18030 でエンコードされた既存のプログラムまたはデータがあって、 |それらを RHEL4 にマイグレーションする場合は、RHEL4 で zh_CN.UTF8 のロケールにより |プログラムを実行してデータを適切に表示できるようにするために、 |それらを iconv で前処理して utf-8 エンコードに変換してください。 | |

- |64 ビット環境 (AMD64 または zSeries 64 ビット・プラットフォームなど) |で miniChinput (中国語 (簡体字) の XIM サーバー) を使用した RHEL 3 において、 |Java で予期しない動作が発生する可能性があります。 |Red Hat の指示を http://www.redhat.com で参照してください。 |Red Hat Bugzilla 番号 RIT75701 を参照してください。 | |

- |ami (韓国語 XIM サーバー) を使用した RHEL 3 で、 |64 ビット環境 (AMD64 または zSeries 64 ビット・プラットフォームなど) |において Java で予期しない動作が発生する可能性があります。 |Red Hat の指示を http://www.redhat.com で参照してください。 |Red Hat Bugzilla 番号 RIT73605 および RIT75708 を参照してください。 | |

- |xcin (中国語 (繁体字) XIM サーバー) を使用した RHEL 4 で、 |64 ビット環境 (AMD64 または zSeries 64 ビット・プラットフォームなど) |において Java でセグメンテーション障害などの予期しない動作が発生する可能性があります。 |Red Hat の指示を http://www.redhat.com で参照してください。 |Red Hat Bugzilla 番号 RIT78430 を参照してください。 | |

- |日本語、中国語、および韓国語ユーザーの場合、 |XIM を使用して、Web ブラウザーの Java アプレットのテキスト・コンポーネントにその文字を入力することができません。 |この制限は、XEmbed が X11 ライブラリー・ファイルの修正を必要としているために発生します。 |この状態を避けるには、-Dsun.awt.noxembed=true システム・パラメーターを指定して XEmbed を使用不可にしてください。 |このオプションを設定するには、コントロール・パネルを使用して次のようにします。 | |
  |
  1. Java Plug-in コントロール・パネルを開いて、「Java」タブに進みます。
  |
  2. 「Java アプレットのランタイム設定 (Java Applet Runtime Settings)」で「表示 (View)」ボタンをクリックします。
  |
  3. 「Java ランタイム・パラメーター (Java Runtime Parameters)」に -Dsun.awt.noxembed=true を入力し、 |「OK」をクリックします。
  |
  4. 「適用 (Apply)」をクリックします。
  |
  5. ブラウザーを開始します。
  | |

## Linux IA 32 ビットに関する制限

- アラビア語テキストのユーザーの場合、 Matrox ビデオ・カードと アクセラレーション・カードを使用可能にして Linux を使用すると、drawString を 使用して大きなフォントを表示する際に文字にひずみが生じる場合があります。 この問題は、これらのカードのドライバーに原因があります。 この問題の回避方法として、デバイスの加速を使用不可に設定することをお勧めします。

- SLES 9 NPTL において、パラレル・ポート・ドライバーが原因でカーネル・クラッシュが発生し、 Java スレッドが停止されます。JVM は、ガーベッジ・コレクションのスレッドを中断しようとしたときにこのクラッシュを検出し、 コア・ファイルと「JVMLH030: すべてのスレッドを中断しようとしているときにスレッドが消失しています (JVMLH030: threads are disappearing when trying to suspend all threads)」というメッセージを生成してクラッシュします。

  この問題に対して、SUSE Bugzilla レポート 47947 があげられています。 このバグは、SLES 9 Service Pack 1 で修正されています。

## Linux AMD64 の制限

| |
- AMD64 SMP システムにおける BIOS 設定に関する重要な注: | |

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

## Linux PPC 32 ビットおよび 64 ビットに関する制限

- Java コードが JNI 呼び出しを使用していて、特定の呼び出しに 9 以上の浮動またはダブル・パラメーターがある場合には、そのC コードは GNU C コンパイラー (GCC) の gcc-2.95.3 Free Software Foundation (FSF) レベルでコンパイルする必要があります。

- XFree86 Version 3.x を実行している場合には、SIGSEGV エラーを受け取る可能性があります。 この問題を回避するために、XFree86 Version 4.x の使用をお勧めします。

- 日付が 1970 より前の日付に設定されている場合には、Java を開始しようとすると例外エラーになります。 この問題を回避するには、マシンを手動で現在日付に設定してください。

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

- 64 ビット・カーネルの 32 ビット・モードで IOCTL 機能が実装されていないために、 JavaComm は、SLES 9 および RHEL 4 においてシリアル・ポート操作をサポートできません。 この制限は、SLES 9 SP2 (Bugzilla 番号 49787) および RHEL 4 アップデート 1 (Bugzilla 番号 144904) で解決されています。

## Linux PPC 64 ビットに関する制限

- デフォルトの gcc クロスコンパイラー (Version 3.2-49) では、 いくつかのエラーが発生します。 共用ライブラリー libFileStat.so を生成するには、`/opt/cross/bin/powerpc64-linux-gcc-shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c` を実行します。 ここで、`<SDK_PATH>` はインストール済みの SDK ディレクトリーへのパスです。

## Linux zSeries 64 ビットに関する制限

以下の制限は、Linux zSeries 64 ビットの中国語および台湾語ユーザーに適用されます。

- 中国語および台湾語のインプット・メソッド・サーバー (xcin) は、Version 5.0 ではテストされていません。

## Linux zSeries 31 ビットおよび 64 ビットに関する制限

- サウンド・カードのないマシンでオーディオを使用する場合、Java による サウンドの再生時に、メモリー不足を示すエラー・メッセージを受け取ることがあります。 このメッセージはコンソールに表示されますが、Java アプリケーションには影響がありません。

- 現在のディストリビューションの Linux カーネルは Internet Protocol Version 6 (IP6) のサポートを提供していますが、これを使用していて問題が起こる場合があります。 Java からの IP6 のサポートがこのリリースに組み込まれていますが、Java コマンドの -Djava.net.preferIPv4Stack=true オプションでこのサポートをオフにすることをお勧めします。 IP6 を完全にサポートするカーネルをインストールする場合には、このオプションは必要ありません。

- |高解像度設定の X Windows サーバーで zSeries 31 ビットまたは 64 ビットの Java を使用する場合、 |Motif AWT での AWT Choice コンポーネントのフォント・グリフが切り取られることがあります。 |この状態を避けるには、解像度設定を下げるか、Motif AWT の代わりに XAWT を使用してください。 |

# 本書に関するご意見

`http://www.ibm.com/jp/manuals/` の「ご注文について」をご覧ください。

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

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

# 特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。 本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。 本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について 実施権を許諾することを意味するものではありません。 実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

- 〒106-0032
  東京都港区六本木 3-2-31
  IBM World Trade Asia Corporation
  Licensing

以下の保証は、国または地域の法律に沿わない場合は、適用されません。

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、 商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、 改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、 便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものでは ありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部では ありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム（本プログラムを含む）との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

- JIMMAIL@uk.ibm.com
  [Hursley Java Technology Center (JTC) contact]

本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で 決定されたものです。 そのため、他の操作環境で得られた結果は、異なる可能性があります。 一部の測定が、開発レベルのシステムで行われた可能性がありますが、 その測定値が、一般に利用可能なシステムのものと同じである保証はありません。 さらに、一部の測定値が、推定値である可能性があります。 実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、 他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

## 商標

IBM、iSeries、pSeries、および zSeries は、IBM Corporation の商標です。

Intel は、Intel Corporation の米国およびその他の国における商標です。

Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における商標です。

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

この製品は、一部分 FreeType Project の作業にも基づいています。Freetype の詳細については、http://www.freetype.org を参照してください。

この製品には、The Apache Software Foundation (http://www.apache.org/) によって開発されたソフトウェアが含まれています。