IBM 32-bit SDK for Windows platforms, Java Technology Edition,バージョン 6

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



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

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

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

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

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



原 典:

IBM 32-bit SDK for Windows platforms, Java Technology Edition, Version 6

SDK and Runtime Guide

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

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


第1刷 2007.9
Copyright International Business Machines Corporation 2003, 2007. All rights reserved.

(C) Copyright IBM Japan 2007

目次

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

前書き

本書には、IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) Technology Edition, Version 6 の概説と、 Sun の実装と対比した IBM の実装の相違点に関する具体的な情報が記載されています。

本書は、Sun の Web サイト (http://java.sun.com) の詳細な資料と一緒にお読みください。

SDK および Runtime Environment は、次の製品でサポートされています。

以下の仮想化環境がサポートされています。

IPv6 は Windows XP および Windows Server 2003 でのみサポートされています。

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

このユーザー・ガイドは、リリースの一部であり、その特定のリリースにのみ適用可能です。使用しているリリースに適切なユーザー・ガイドであることを確認してください。

用語「Runtime Environment」と「Java 仮想マシン」は、本書では同じ意味で使用されています。

|本書のこのバージョンでの技術的な変更は、小さな変更や明らかな変更を除き、インフォメーション・センターでは青色の山形文字で示され、HTML やカラー印刷コピーでは、変更箇所の左側に赤の縦線が表示され、PDF では変更箇所の左側に縦線が表示されています。

このプログラム・コードは、航空機オンライン制御、航空管制、航空ナビゲーション、航空通信などを含む (がこれに制限されない) リアルタイム・アプリケーション、および核施設の設計、建設、稼働、または保守における使用を想定しておらず、また、そのような使用のために設計されたものでもありません。

概説

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

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

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

さらに、Java Communications のアプリケーション・プログラミング・インターフェース (API) パッケージ が Runtime Environment for Windows と一緒に使用するために提供されています。 これについては、Java Communications API (JavaComm) の使用を参照してください。

バージョンの互換性

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

IBM 32-bit SDK for Windows v6 は、Microsoft Visual Studio .NET 2003 を使用して作成されました。

リリース間での互換性について詳しくは、以下の Sun の Web サイトを参照してください。

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

他の製品 (IBM WebSphere(R) Application Server など) の一部として SDK を使用していて、以前のレベルの SDK (v5.0 など) からアップグレードする場合、直列化されたクラスに互換性がないことがあります。ただし、クラスは Service Refresh 間で互換性を持ちます。

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

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

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

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

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

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

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

Runtime Environment のクラスおよびツール

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

SDK ツールおよび参照情報

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

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

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

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

SDK のインストールにはインストール・ウィザードまたは圧縮ファイルを使用します。SDK の構成には環境変数、コマンド行オプション、およびプロパティー・ファイルを使用します。

インストール前の確認事項

SDK または Runtime Environment パッケージをインストールするには、該当するインストール・パッケージをダウンロードします。すべてのパッケージを同一ディレクトリーにダウンロードしており、一時ディレクトリーに十分なスペースがあることを確認します。

パッケージとパッケージ内のファイルの名前のリストについてはパッケージのインストールを参照してください。パッケージのファイル名は変更しないでください。

インストールを開始する前に、インストール中に使用される C:¥WINDOWS¥TEMP ディレクトリーに十分なスペースがあることを確認してください。インストール中に TEMP ディレクトリーに必要な一時スペースの量を次に示します。

十分な一時スペースがないと、インストール・プログラムはエラーを生成し、インストールを強制終了します。十分な一時スペースがあるにもかかわらずこのメッセージが表示される場合は、インストールするパッケージが完全にダウンロードされているかどうかを確認してください。これを確認するには、ダウンロードしたパッケージのファイル・サイズと、パッケージのダウンロード元 Web ページに示されているファイル・サイズを比較します。

パッケージのインストール

個別にインストールできるパッケージは、 SDK、Runtime Environment、 Javacomm、資料、デモなど、多数あります。

インストールできるパッケージは以下のとおりです。

その他のパッケージは、圧縮ファイルとして提供されます。

SDK または Runtime Environment を圧縮パッケージからインストールする場合、Web Start または Java Plug-in は使用できません。また、コントロール・パネルに組み込まれる「更新」タブは機能しません。

手動 (対話式) インストール

SDK または JRE を 1 つのクライアントにインストールするには、手動インストールを使用します。

  1. ibm-java-sdk-60-win-i386.exe (SDK) または ibm-java-jre-60-win-i386.exe (Runtime Environment のみ) を起動します。
  2. インストール・ウィザードの指示に従って操作します。

    Runtime Environment は、デフォルトでは C:¥Program Files¥IBM¥Java60¥jre ディレクトリーにインストールされます。

    SDK インストール・パッケージをダウンロードした場合は、インストールするコンポーネントを選択できます。

    インストール・ウィザードで、次のオプションが表示されます。

    Windows Vista では、インストール言語の選択後の処理が遅れることがあります。

    インストールが失敗し、エラー・メッセージ「変換適用中にエラーが発生しました (Error applying transform)」が示される場合は、Windows インストーラー構成情報が壊れています。このエラーを修正するには、http://support.microsoft.com/kb/290301 の Windows Installer Cleanup ユーティリティーを使用して、破損した Windows インストーラー構成情報を除去します。

システム Java 仮想マシンとしての Runtime Environment のインストール

Runtime Environment を (SDK インストール・パッケージの一部として、あるいは Runtime Environment インストール・パッケージから) インストールするときに、Runtime Environment をシステム Java 仮想マシン (JVM) としてインストールするかどうかを決定するよう求められます。システム JVM としてインストールする場合は、インストール・プログラムにより java.exe、javacpl.cpl、javaws.exe、および javaw.exe ランチャーが Windows システム・ディレクトリーにコピーされます。

java.exe または javaw.exe が既に Windows システム・ディレクトリーにある場合は、既存のバージョンを新規バージョンで上書きするかどうかを尋ねるプロンプトが出されます。これらのファイルを Windows システム・ディレクトリーにインストールすると、この Runtime Environment がシステムのデフォルト JVM になります。また、「現在のバージョン」のレジストリー・キーがこのインストールに合わせて設定されます。

注: Runtime Environment をシステム JVM としてインストールする場合は、java.exe と javaw.exe だけが Windows システム・ディレクトリーにコピーされます。その他のプログラム (javac.exe や appletviewer.exe など) はコピーされません。

自動インストール

SDK または JRE を複数のクライアントにインストールするには自動インストールを使用します。

自動インストールを作成するには、まず手動インストールを実行し、インストール中の選択内容を記録する応答ファイル (setup.iss) を作成します。作成する応答ファイルの内容は、このファイルを使用する予定のすべてのコンピューターで正しいものでなければなりません。必要に応じて、構成が異なるコンピューターにパッケージをインストールするときに使用する複数の応答ファイルを作成します。

インストール実行中に応答ファイルを作成するには、コマンド・プロンプトから次のように入力します。

ibm-java-sdk-60-win-i386 /r

または

ibm-java-jre-60-win-i386 /r

ご使用の Windows 製品に応じて、応答ファイル (setup.iss) が C:¥Windows または C:¥Winnt のいずれかのディレクトリーに作成されます。

対話式インストールの実行中に次のメッセージが表示されることがあります。

別の Java Runtime Environment が現在 System JVM としてインストールされています。
このバージョンを上書きする場合は「はい」を選択し、このインストールを終了する場合は
「いいえ」を選択してください。
(Select Yes to overwrite this version or No to exit this installation.)

このメッセージが表示されたら、「いいえ」を選択してインストールを終了します。Windows のシステム・ディレクトリーに移動し、次の 2 つのファイルを削除します。

ファイルを削除したら、このセクションの冒頭に示されているコマンドを使用して対話式インストールをもう一度実行します。

自動インストールを実行するシステムの C:¥Windows ディレクトリーに setup.iss 応答ファイルをコピーします。ファイルをコピーしたら、コマンド・プロンプトから次のように入力します。

ibm-java-sdk-60-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log
ibm-java-jre-60-win-i386 /s /f1c:¥Windows¥setup.iss /f2c:¥setup.log
注:
  1. /f1/f2 の後にはスペースはありません。
  2. /f1 フラグには、応答ファイルの名前と場所を指定します。/f2 フラグには、ログ・ファイルの名前と場所を指定します。

インストールが正常に完了すると、ログ・ファイルに ResultCode=0 というストリングが出力されます。 インストールが失敗すると、ログ・ファイルに 0 以外の結果コードが出力されます。

IBM Accessibility Bridge の使用可能化

IBM Accessibility Bridge がインストールされますが、デフォルトでは使用不可に設定されています。IBM Accessibility Bridge を使用可能にするには、Accessibility.properties ファイルの assistive_technologies 項目のコメントを外します。

Accessibility.properties ファイルは jre/lib ディレクトリーに格納されています。次のに示す行の先頭から # を削除します。

#assistive_technologies=JawBridge

次に示す Web サイトに、アクセス支援ユーティリティーの詳しい情報があります。

http://java.sun.com/products/jfc/accessibility.html

Java Accessibility サポートを使用不可にする

Java 支援技術をサポートしていない Java アプリケーションの (特にネットワーク・リンク経由での) JVM ロード・パフォーマンスを改善するため、 Java Accessibility サポートを使用不可にできます。Java Accessibility サポートを使用不可にするには、JAVA_ASSISTIVE 環境変数を OFF に設定します。

この環境変数が OFF に設定されていると、Accessibility.properties ファイルで JawBridge などの支援技術が有効に設定されている場合でも、これらの支援技術を使用できません。

欧州言語ユーザーを対象とした情報

Windows では、1 つのプロセスに、ANSI (または Windows) と OEM (または DOS) という 2 つのコード・ページがあります。console.encoding システム・プロパティーが設定されていない場合は、javaw コマンドでは常に ANSI コード・ページが使用されます。

通常、コマンド・ウィンドウでは OEM コード・ページが使用されます。Java コンソール出力では、Java を開始したコマンド・ウィンドウのコード・ページが使用されます。ただし、javaw コマンドでは常に ANSI コード・ページが使用されます。コンソール出力に使用するコード・ページを指定するには、java またはjavaw ランチャーの -Dconsole.encoding オプションを使用します。例えば、-Dconsole.encoding=Cp1252 と指定すると、すべてのコンソール出力で Windows ANSI Latin1 コード・ページ (1252) が使用されます。

パスの設定

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

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

  echo %PATH%

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

  1. SDK または Runtime Environment を C:¥Program Files¥IBM¥Java60¥ にインストールした場合、以下のディレクトリーを PATH 環境変数に追加します。
  2. すべてのコマンド・プロンプト・ウィンドウを閉じて再オープンし、新しい PATH 環境変数をアクティブにします。

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

javac Myfile.Java

クラスパスの設定

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

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

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

    echo %CLASSPATH%

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

アンインストール

SDK または Runtime Environment をアンインストールするには、Windows の「プログラムの追加と削除」ユーティリティーを使用します。

SDK をアンインストールするには、自動インストールまたは手動インストールのどちらでインストールを実行した場合でも、次の手順に従います。

  1. Windows デスクトップの「マイ コンピュータ」をダブルクリックします。
  2. 「コントロール パネル」をダブルクリックします。
  3. 「プログラムの追加と削除」をダブルクリックします。
  4. リストの「IBM 32-bit SDK for Java 2 v6」をクリックして、「変更/削除」をクリックします。
  5. OK」をクリックします。

この手順では、インストーラーを使用してインストールされたすべてのパッケージが削除されます。Java Communications API パッケージ (Java Communications API のアンインストールを参照) や、圧縮パッケージから解凍した追加ファイルは削除されません

注: 削除されなかったファイルまたはレジストリー項目があることを通知する警告メッセージが表示されることがあります。Windows が、特定のファイルがまだ使用中であると認識するためにこの警告が表示されます。このようなファイルまたはレジストリー項目は、次回のリブート時に削除されます。

SDK またはRuntime Environment をアンインストールするために必要な権限がない場合は、「Error1325.launchpad は有効な短ファイル名ではありません。」が表示されます。SDK または Runtime Environment をアンインストールするには、正しい権限を復元します。

IBM 32-bit SDK for Windows, v6 と V1.3.1 およびそれ以前のバージョンを複数インストールして維持している場合、v6 がシステムにインストールされている状態で、古いバージョンをアンインストールすると、V1.3.1 アンインストーラーにより、v6 バージョンに必要な次のレジストリー・キーとすべてのサブキーが削除されます。このため、インストールされている v6 が破損します。

したがって、V1.3.1 をアンインストールした場合は、その後に v6 を再インストールしてください。このアンインストーラーの制限は、V1.4.0 およびそれ以降のリリースでは修正されています。

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

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

java および javaw コマンド

java および javaw コマンドの簡単な概要です。

目的

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

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

使用法

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

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

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

パラメーター

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

バージョン情報の取得

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

  1. コマンド・プロンプトを開きます。
  2. 以下のコマンドを入力します。
        java -version
    以下に類似した情報が表示されます。
    java version "1.6.0-internal"
    Java(TM) SE Runtime Environment (build 20070227_01)
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT enabled)
    J9VM - 20070226_11758_lHdSMR JIT  - dev_20070215_1800 GC   - 20070208_AA)
    ビルド日とバージョンが変更されます。

| |

また、以下のコマンドを入力すると、クラスパス、ブート・クラスパス、および拡張ディレクトリーにあるすべての利用可能な jar ファイルのバージョン情報を表示することもできます。

|
java -Xjarversion
|

以下に類似した情報が表示されます。

|
...
|C:¥Program Files¥IBM¥Java60¥jre\lib\ext\ibmpkcs11impl.jar  VERSION: 1.0 build_20070125
|C:¥Program Files¥IBM¥Java60¥jre\lib\ext\dtfjview.jar
|C:¥Program Files¥IBM¥Java60¥jre\lib\ext\xmlencfw.jar  VERSION: 1.00, 20061011  LEVEL: -20061011
|
|...
|

利用可能な情報はそれぞれ jar ファイルごとに異なり、jar ファイルのマニフェストにある Implementation-Version および Build-Level プロパティーから取得されます。

Java オプションとシステム・プロパティーの指定

オプション・ファイルや環境変数を使用して、コマンド行に Java オプションおよびシステム・プロパティーを指定できます。

Java オプションを指定するこれらのメソッドは、優先順位の順序でリストされます。

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

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

java -Xint -Xjit myClass

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

標準オプション

標準オプションの定義

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

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

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

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

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

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

java -Xargencoding '¥u0048ello¥u0057orld'

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

Java ファイルの自動実行

Java クラスまたは JAR ファイルを Windows エクスプローラから自動的に開始するように設定するには、Windows エクスプローラの「ツール」 -> 「フォルダ オプション」 -> 「ファイルの種類」オプションを使用します。

あるいは、コマンド・プロンプトから次のように入力します。

assoc .class=javaclass 
ftype javaclass=C:¥Program Files¥IBM¥Java60¥jre¥bin¥java.exe''%l''%*'

注:
  1. %l は数字 1 です。文字 l ではありません。
  2. Java が C:¥Program Files¥IBM¥Java60¥ 以外のディレクトリーにインストールされている場合には、インストール・ディレクトリーに置き換えます。

ネイティブ支援テクノロジーを使った Java アプリケーションの実行

Sun では、スクリーン・リーダー、Java アプリケーションにおける Java Accessibility サポートへのアクセスなど、ネイティブ Windows 支援テクノロジーを使用するための、Java Access Bridge を提供しています。これらのネイティブ Windows 支援テクノロジーは、Java Access Bridge の呼び出しをサポートする必要があります。

Sun から入手できる Java Access Bridge には、5 つのファイル (access-bridge.jar、jaccess.jar、accessibility.properties、JavaAccessBridge.dll および WindowsAccessBridge.dll) を正しいディレクトリーに配置するインストーラーが組み込まれています。IBM は、JawBridge との使用に適切なディレクトリーで jaccess.jar のコピーを出荷します。

Swing アプリケーションで Windows 2000 Magnifier が機能するように IBM Accessibility Bridge (JawBridge) が既に使用可能になっていて、 Java Access Bridge と同時に JawBridge を使用可能にしたい場合は、 accessibility.properties ファイル内の行を、以下のように編集してください。

assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge

両方のブリッジを非アクティブにするには、先頭に # を挿入して、 その行をコメント化してください。 次の Web サイトで、Java Access Bridge のダウンロード方法が分かります。

http://java.sun.com/products/jfc/accessibility.html

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

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

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

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

JIT の使用不可化

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

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

JIT の使用可能化

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

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

JIT の状況は -version オプションを使用して判別できます。

java ランチャーを -version オプションで実行します。 コマンド・プロンプトで、次のように入力します。

    java -version

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

(JIT disabled)

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

(JIT enabled)

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

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

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

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

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

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

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

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

-Xgcpolicy オプションは、ガーベッジ・コレクターの振る舞いを制御します。これは、アプリケーションおよびシステム全体のスループットと ガーベッジ・コレクションに起因する休止時間とのトレードオフを図ります。

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

-Xgcpolicy:optthruput
(デフォルトおよび推奨値。) 非常に高いスループットをアプリケーションに提供しますが、 代償として時折休止します。
-Xgcpolicy:optavgpause
ガーベッジ・コレクション休止に費やされる時間を削減し、 ヒープ・サイズの増加がガーベッジ・コレクション休止の長さに与える影響を制限します。非常に大規模なヒープが構成にある場合には、optavgpause を使用します。
-Xgcpolicy:gencon
並行と世代別の GC を組み合わせた使用を要求し、 ガーベッジ・コレクションの休止に費やされる時間を最小にするよう支援します。

休止時間

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

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

デフォルトの ガーベッジ・コレクション値の -Xgcpolicy:optthruput では、 非常に高いスループットがアプリケーションにもたらされますが、 こうした一時休止 (ヒープ・サイズとガーベッジの質により数ミリ秒からかなりの秒数まであり得る) が 代償になっています。

休止時間の削減

JVM では、並行ガーベッジ・コレクションと世代別ガーベッジ・コレクションという 2 つの手法を使用して休止時間を削減します。

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

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

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

ヒープがフルの環境

Java ヒープがフルに近く、再利用できるガーベッジが少ししかない場合、即時使用可能なスペースがないため、新規オブジェクト用の要求がすぐには満たされないことがあります。

ヒープが容量いっぱいに近い状態で操作されている場合、どちらのガーベッジ・コレクション・オプションが使用されているのかに関係なく、アプリケーション・パフォーマンスは悪くなります。また、さらにヒープ・スペースの要求が続けば、アプリケーションは OutOfMemoryError を受け取り、その例外がキャッチされ処理されなければ、JVM は終了します。この時点で、JVM は診断時に使用できる Javadump ファイルを生成します。このような状態の場合、-Xmx オプションを使用してヒープ・サイズを増やすか、 使用中のオブジェクトの数を減らすことをお勧めします。

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

ユーロ記号のサポート

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

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

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

| | |

インドおよびタイ語の入力方式の使用

|
|

バージョン 6 では、インドおよびタイ語の入力方式はデフォルトでは使用できません。インドおよびタイ語の入力方式を使用するには、入力方式の jar ファイルを Java 拡張パスに手動で組み込む必要があります。

|

バージョン 5.0 では、入力方式の jar ファイルは jre\lib\ext ディレクトリーに含まれており、JVM によって自動的にロードされていました。バージョン 6 では、入力方式の jar ファイルは jre\lib\im ディレクトリーに含まれており、インドおよびタイ語の入力方式を使用可能にするには、これを Java 拡張パスに手動で追加する必要があります。これは、以下のいずれかの方法を使用して実現できます。

| |

|

SDK または Runtime Environment を別のディレクトリーにインストールした場合、SDK または Runtime Environment をインストールした |ディレクトリーで C:¥Program Files¥IBM¥Java60¥ を置き換えてください。

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

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

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

| | |

XML の使用

|
|

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

|

|

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

|

| |

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

|

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

|
|
XML4J 4.5
|
|

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

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

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

|
|
XL XP-J 1.1
|
|

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

|
|
XL TXE-J 1.0.1 Beta
|
|

バージョン 5.0 では、IBM SDK for Java に XSLT4J のコンパイラーとインタープリターが組み込まれていました。 |XSLT4J インタープリターがデフォルトで使用されていました。

| |

バージョン |6 では、IBM SDK for Java に XL TXE-J が組み込まれています。XL TXE-J には、XSLT4J 2.7.8 インタープリターと新規 XSLT コンパイラーが組み込まれています。 |この新規コンパイラーはデフォルトで使用されます。XSLT4J コンパイラーはすでに |IBM SDK |for Java に組み込まれていません。XL TXE-J へのマイグレーションについては、XL-TXE-J のマイグレーションを参照してください。

| |

XL TXE-J は、次の規格をサポートしています。 |

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

| |

XML プロセッサーの選択

|

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

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

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

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

| |

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

|
|

デフォルト XSLT プロセッサーは、XSLT4J インタープリターから XL TXE-J コンパイラーに置き換わりました。新しいライブラリーに対応するようにアプリケーションを準備するには、次の手順で操作します。

|

|

同じ変換を複数回適用する場合、XL TXE-J コンパイラーは XSLT4J インタープリターよりも高速です。各変換を一度ずつしか実行しない場合は、 |XL TXE-J コンパイラーのほうが XSLT4J インタープリターよりも低速です。これは、コンパイルと最適化のオーバーヘッドが原因です。

|

XSLT4J インタープリターを引き続き XSLT プロセッサーとして使用するには、javax.xml.transform.TransformerFactory サービス・プロバイダーを |org.apache.xalan.processor.TransformerFactoryImpl に設定してください。

|

XL-TXE-J コンパイラーにマイグレーションするには、次の手順で操作します。

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

XML 参照情報

|
|

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

| | |

XL XP-J 参照情報

|
|

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

|

| |

サポートされない機能
|

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

|

|

| |

XMLInputFactory 参照
|

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

| |||||||||||||||||||||||||||||||||||||||||||
表 2.
プロパティー名 サポートの有無
javax.xml.stream.isValidating なし。XL XP-J スキャナーでは検証はサポートされていません。
javax.xml.stream.isNamespaceAware あり (true および false がサポートされています)。DOMSource から作成された XMLStreamReader では、名前空間の処理は、DOM ツリーを作成するときに使用されたメソッドによって異なります。この値の効果はありません。
javax.xml.stream.isCoalescing あり
javax.xml.stream.isReplacingEntityReferences あり。DOMSource から作成された XMLStreamReader では、DOM ツリーでエンティティーが既に置換されている場合はこのパラメーターの効果はありません。
javax.xml.stream.isSupportingExternalEntities あり
javax.xml.stream.supportDTD なし。DTD は常にサポートされています。この値を false に設定しても効果がありません。
javax.xml.stream.reporter あり
javax.xml.stream.resolver あり
|

XL XP-J では、オプションのメソッド createXMLStreamReader(javax.xml.transform.Source) もサポートされています。このメソッドは、DOM ソースおよび SAX ソースからの StAX リーダーを作成できるようにします。

|

| |

XMLStreamReader 参照
|

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

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

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

|

| |

XMLOutputFactory 参照
|

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

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

| |

XMLStreamWriter 参照
|

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

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

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

| | |

XL TXE-J 参照情報

|
|

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

|

| |

機能の比較表

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
表 6. XSLT4J インタープリター、XSLT4J コンパイラー、XL TXE-J コンパイラーの機能の比較
機能 XSLT4J インタープリター (組み込み) XSLT4J コンパイラー (非組み込み) XL TXE-J コンパイラー (組み込み)
http://javax.xml.transform.stream.StreamSource/feature 機能 あり あり あり
http://javax.xml.transform.stream.StreamResult/feature |機能 あり あり あり
http://javax.xml.transform.dom.DOMSource/feature 機能 あり あり あり
http://javax.xml.transform.dom.DOMResult/feature 機能 あり あり あり
http://javax.xml.transform.sax.SAXSource/feature 機能 あり あり あり
http://javax.xml.transform.sax.SAXResult/feature 機能 あり あり あり
http://javax.xml.transform.stax.StAXSource/feature 機能 あり なし あり
http://javax.xml.transform.stax.StAXResult/feature 機能 あり なし あり
http://javax.xml.transform.sax.SAX TransformerFactory/feature |機能 あり あり あり
http://javax.xml.transform.sax.SAX TransformerFactory/feature/xmlfilter |機能 あり あり あり
http://javax.xml.XMLConstants/feature/secure-processing |機能 あり あり あり
http://xml.apache.org/xalan/features/incremental 属性 あり なし なし
http://xml.apache.org/xalan/features/optimize 属性 あり なし なし
http://xml.apache.org/xalan/properties/source-location |属性 あり なし なし
translet-name 属性 該当なし あり あり (新規名付き)
destination-directory 属性 該当なし あり あり (新規名付き)
package-name 属性 該当なし あり あり (新規名付き)
jar-name 属性 該当なし あり あり (新規名付き)
generate-translet 属性 該当なし あり あり (新規名付き)
auto-translet 属性 該当なし あり あり (新規名付き)
use-classpath 属性 該当なし あり あり (新規名付き)
enable-inlining 属性 なし あり なし (TL TXE-J では廃止)
indent-number 属性 なし あり あり (新規名付き)
debug 属性 なし あり あり (新規名付き)
Java 拡張 あり あり (短縮構文のみ。xalan:component/xalan:script |構文はサポートされません。)
JavaScript 拡張 あり なし なし
拡張エレメント あり なし なし
EXSLT 拡張機能 あり あり (動的は除く) あり (動的は除く)
リダイレクト拡張 あり あり (redirect:open および redirect:close は除く) あり
出力拡張 なし あり あり
nodeset 拡張 あり あり あり
NodeInfo 拡張機能 あり なし なし
SQL ライブラリー拡張 あり なし なし
pipeDocument 拡張 あり なし なし
evaluate 拡張 あり なし なし
tokenize 拡張 あり なし なし
XML 1.1 あり あり あり
|

| |

|

Process コマンドでは、StAX ストリーム処理を使用して変換を行うには -FLAVOR sr2sw を、StAX イベント処理の場合は -FLAVOR er2ew を使用してください。

|

新規コンパイラーは、 |org.apache.xalan.xsltc.dom.XSLTCDTMManager サービス・プロバイダーを検索しません。その代わり、StreamSource が使用されている場合、コンパイラーはハイパフォーマンス XML パーサーに切り替わります。

|

XL TXE-J では、インライン化は廃止されました。 |

| |

org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl クラスはサポートされなくなりました。

| |

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

|
|

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

|

|

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

|

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

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

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

Java Debugger (JDB)

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

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

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

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

jdb -help

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

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

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

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

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

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

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

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

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

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

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

JVM のシグナルの処理方法

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

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

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

シグナルが外部で生成されると (例えば、CTRL-BREAK キーを押した場合)、シグナル・ハンドラーの新規スレッドが作成されます。この場合、 JVM シグナル・ハンドラーがその処理を実行します。このシグナル用アプリケーション・ハンドラーが インストールされていて、-Xnosigchain コマンド行オプションを指定しなかった場合には、 このシグナル用のアプリケーション・ハンドラーが呼び出されます。

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

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

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

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

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

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

JVM が使用するシグナル

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

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

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

表 7. JVM が使用するシグナル
シグナル名 シグナル・タイプ 説明 -Xrs による使用不可
SIGINT (2) 割り込み 対話式アテンション (CTRL-C)。 JVM は正常に終了します。 あり
SIGTERM (15) 割り込み 終了要求。JVM は正常に終了します。 あり
SIGBREAK 制御 端末からのブレーク・シグナル。デフォルトでは、Javadump が起動されます。 あり

IBM JVM は、構造化された例外処理 および SetConsoleCtrlHandler() API を使用します。これらは、-Xrs で使用不可になります。Windows では、-Xnosigchain は無視されます。

-Xrs (シグナル使用の削減) オプションを使用して、 JVM がほとんどのシグナルを処理してしまうのを防止します。詳しくは、 Sun の 『Java application launcher』ページを参照してください。

JVM スレッド上のシグナル 2 (SIGINT) および 15 (SIGTERM) により、 JVM はシャットダウンします。したがって、アプリケーション・シグナル・ハンドラーでは、JVM を必要としなくなった場合を除き、 リカバリーを試みるべきではありません。

ネイティブ・コード・ドライバーをシグナル・チェーニング・ライブラリーにリンクする

Runtime Environment にはシグナル・チェーニングが含まれています。シグナル・チェーニングにより、JVM は、独自のシグナル・ハンドラーをインストールするネイティブ・コードとの、より効率的な相互操作が可能となります。

シグナル・チェーニングにより、アプリケーションでは、msvcrt.dll の前に共用ライブラリー jsig.dll にリンクしてロードすることが可能になります。jsig.dll ライブラリーにより、signal() の呼び出しが確実にインターセプトされ、それらのハンドラーが JVM のシグナル・ハンドラーを置き換えることがなくなります。代わりに、これらの呼び出しは、新しいシグナル・ハンドラーを保管するか、または JVM がインストールしたハンドラーの後にそれらを「チェーニング」します。後で、これらのシグナルのいずれかが生じ、JVM をターゲットとしたものではないことが分かった場合、プリインストールされたハンドラーが起動します。

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

環境変数 JAVA_HOME は、SDK の場所 (例えば C:¥Program Files¥IBM¥Java60¥) に設定してください。

jsig.dll を使用するには、それを JVM を作成または組み込むアプリケーションとリンクします。

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

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

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

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

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

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

大規模ページをサポートするシステムでこのサポートを使用可能にするには、 -Xlp オプションを指定して Java を始動します。

大規模ページは、多くのメモリーを割り振って頻繁にそのメモリーにアクセスする アプリケーションのパフォーマンスを向上させるために使用するものです。 大規模ページによるパフォーマンスの向上は、 主に Translation Lookaside Buffer (TLB) のミスの数を減らすことによって実現します。 TLB は、より大きな仮想メモリー範囲をマップし、それにより、この向上をもたらします。

JVM が大規模ページを使用するためには、システムで、十分な数の連続した大規模ページが使用可能でなければなりません。 十分なページが使用可能であっても、大規模ページを割り振れない場合、大規模ページが連続していない可能性があります。

大規模ページの割り振りは、JVM ユーザーのローカル管理ポリシーが「Lock pages in memory」を許可するように構成されている場合にのみ、正常終了します。

CORBA サポート

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

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

GIOP 1.2 のサポート

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

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

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

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

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

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

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

Interoperable Naming Service のサポート

この SDK は、資料「ptc/00-08-07」で OMG によって定義されているように、 Interoperable Naming Service をサポートします。この資料は、以下のサイトから入手できます。

http://www.omg.org/cgi-bin/doc?ptc/00-08-07

一時ネーム・サーバー (tnameserv コマンド) が使用するデフォルトのポートは、ORBInitialPort パラメーターが指定されていない場合には、900 から 2809 に変更されます。これは CORBA ネーミング・サービス用に IANA (Internet Assigned Number Authority) で登録されているポート番号です。 このデフォルトに依存する プログラムは、このバージョンで作業する場合に更新しなければならない可能性があります。

一時ネーム・サーバーから戻される初期コンテキストは、現在、 org.omg.CosNaming.NamingContextExt です。コンテキスト org.omg.CosNaming.NamingContext への参照が限られている既存のプログラムは、そのまま動作するので、再コンパイルする必要はありません。

ORB は、Interoperable Naming Service 仕様で定義されている -ORBInitRef-ORBDefaultInitRef パラメーターをサポートし、ORB::string_to_object 操作では、現在、 Interoperable Naming Service 仕様で定義されている ObjectURL ストリング・フォーマット (corbaloc: および corbaname:) がサポートされています。

OMG は、サービスを Interoperable Naming Service に登録するのに、 メソッド ORB::register_initial_reference を指定します。しかし、このメソッドは バージョン 6 の Sun Java Core API では使用できません。 現行バージョンでサービスの登録が必要なプログラムは、このメソッドを IBM 内部の ORB 実装クラスで呼び出す必要があります。例えば、サービス「MyService」を登録するには以下のようにします。

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

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

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

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

プロパティーのトレース

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

ORB トレースの例

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

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

制限

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

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

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

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

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

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

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

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

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

表 8. Java SecurityManager を使用して実行中に影響を受けるメソッド
クラス/インターフェース メソッド 必要な権限
org.omg.CORBA.ORB init java.net.SocketPermission resolve
org.omg.CORBA.ORB connect java.net.SocketPermission listen
org.omg.CORBA.ORB resolve_initial_references java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _is_a java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _non_existent java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl OutputStream _request (String, boolean) java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _get_interface_def java.net.SocketPermission connect
org.omg.CORBA. Request invoke java.net.SocketPermission connect
org.omg.CORBA. Request send_deferred java.net.SocketPermission connect
org.omg.CORBA. Request send_oneway java.net.SocketPermission connect
javax.rmi. PortableRemoteObject narrow java.net.SocketPermission connect

ORB 実装クラス

ORB 実装クラスのリストです。

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

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

RMI over IIOP

Java リモート・メソッド呼び出し (RMI) は、分散 Java プログラミングのための簡単なメカニズムです。RMI over IIOP (RMI-IIOP) では、Common Object Request Broker Architecture (CORBA) 標準の Internet Inter-ORB Protocol (IIOP プロトコル) を使用し、基本の Java RMI を拡張して通信を行います。これにより、他の CORBA オブジェクト・リクエスト・ブローカー (ORB) が Java で実装されていても、他のプログラム言語で実装されていても、 それらとの直接対話が可能になります。

以下の資料が利用可能です。

RMI の Connection Handler Pool の実装

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

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

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

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

拡張 BigDecimal

Java 5.0 以降、Sun によりIBM BigDecimal クラスが java.math.BigDecimal として採用されました。com.ibm.math.BigDecimal クラスは IBM が将来使用するものとして予約されており、現在は推奨されていません。既存の Java コードをマイグレーションして、java.math.BigDecimal を使用してください。

新しい java.math.BigDecimal は、以前の java.math.BigDecimal と com.ibm.math.BigDecimal の両方と同じメソッドを使用しています。 java.math.BigDecimal を使用している既存のコードは、そのまま正常に動作します。2 つのクラスは直列化されません。

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

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

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

Java Plug-in の使用

Java Plug-in は Web ブラウザー・プラグインです。ブラウザーでアプレットを実行するには、Java プラグインを使用します。

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

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

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

Java Plug-in では、Internet Explorer、Netscape、Mozilla、 および Mozilla Firefox がサポートされています。

表 9. Java Plug-in でサポートされるブラウザー
ブラウザー サポートされるバージョン
Internet Explorer 6.0 SP1, 7.0
Netscape (Windows Vista ではサポートされません) 7.2
Mozilla (Windows Vista ではサポートされません) 1.7, 1.8
Firefox 2.0

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

Internet Explorer 5.01 は Windows 2000 のデフォルト・ブラウザーですが、サポートされていません。

Secure Static Versioning (SSV) のサポート

静的バージョン管理では、アプレットが、特定の JVM バージョンを実行環境として要求できます。この機能を使用すると、新規 JVM にアップグレードしたシステムに存在する古いセキュリティーの脆弱性をアプレットが悪用することもできるため、Internet Explorer では Secure Static Versioning が使用されるようになっています。

デフォルトでは、最後にインストールされた JVM ですべてのアプレットが実行されます。SSV を無効にするには、次のレジストリー・キーを 0 に設定します。

HKEY_LOCAL_MACHINE¥Software¥IBM¥Java Deployment¥Policy¥EnableSecureStaticVersioning

レジストリー・キーが存在しない場合は、SSV が使用可能になっています。

Internet Explorer でサード・パーティーのブラウザー拡張が使用不可に設定されている場合は、SSV が機能しません。サード・パーティーのブラウザー拡張を使用可能にするには、次の手順を実行します。

  1. Internet Explorer を開きます。
  2. 「ツール」 -> 「インターネット オプション」をクリックします。
  3. 「詳細設定」タブをクリックします。
  4. 「サード パーティ製のブラウザ拡張を有効にする (再起動が必要)」チェックボックスを選択します。

SSV が使用された後にサード・パーティーのブラウザー拡張が使用不可になっても、SSV は機能し続けます。

Mozilla および Firefox ブラウザーを保護するため、Internet Explorer のプラグインによって、Mozilla および Firefox の Plug-in ディレクトリーから Java Plug-in が自動的に削除されます。この処理は、アプレットが Internet Explorer で実行されるたびに生じます。

Mozilla または Firefox に Java Plug-in を再インストールするには、Java コントロール・パネルを使用します。

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

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

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

DBCS パラメーターの使用

Java Plug-in は、2 バイト文字を (例えば、中国語 (繁体字) BIG-5、韓国語、日本語) タグ <APPLET><OBJECT>、および <EMBED> などのパラメーターとしてサポートします。Java Plug-in がパラメーターを解析できるように、HTML 文書の正しい文字エンコード方式を選択しなければなりません。

HTML 文書の文字エンコード方式は、 <HEAD> セクションで <META> タグを使用して次のように指定します。

<meta http-equiv="Content-Type" content="text/html; charset=big5">

この例は、ブラウザーに、中国語 BIG-5 文字エンコード方式を使用して HTML ファイルを解析するように指示するものです。

アプレットの処理

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

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

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

アプレット・ビューアーでアプレットを実行するには、以下のコマンドを使用します。

コマンド・プロンプトで、以下を入力します。

   appletviewer <name>

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

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

appletviewer <demo>¥GraphLayout¥example1.html

ここで、<demo> は、デモ・パッケージを unzip した先の 絶対パスに置き換えます。

Web ページでアプレット・ビューアーを呼び出すには、コマンド・プロンプトで次のように入力します。

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

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

appletviewer -encoding JISAutoDetect sample.html

固有の CLSID

固有の CLSID のセットが Version 6 から IBM JVM に追加されました。

以下が新しい CLSID です。

1ACECAFE-0016-0000-0000-ABCDEFFEDCBA
1ACECAFE-0016-0000-0000-ABCDEFFEDCBB
1ACECAFE-0016-0000-0000-ABCDEFFEDCBC

上記の CLSID は、アプレットの OBJECT タグで参照できます。

また、以下の既存の CLSID も互換性目的でサポートされています。

CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC

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

アプレットをデバッグするには、アプレット・ビューアーの -debug オプションを使用します。

例えば、次のようにします。

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

アプレット・ビューアーを使用してアプレットをデバッグする方法についての資料は、 Sun の Web サイト http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html で参照できます。

Web Start の使用

Java Web Start は、Java アプリケーションのデプロイメントで使用します。

Web Start を使用すると、アプリケーションの起動および管理を Web から直接行うことができます。インストール時間を最小化するために、アプリケーションがキャッシュされます。新規バージョンが使用可能になると、アプリケーションは自動的にアップグレードされます。

Web Start は、http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources に文書化されている、以下の java-vm-args をサポートします。

IBM Web Start では、ガーベッジ・コレクション・ポリシーを設定する -Xgcpolicy もサポートします。

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

Web Start について詳しくは、

アプリケーションのデプロイについて詳しくは、

Web Start の実行

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

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

WebStart Secure の静的バージョン管理

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

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

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

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

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

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

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

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

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

クラス・データの共用によって、複数の JVM がメモリー内の単一スペースを共用できます。

Java 仮想マシン (JVM) では、ディスクのメモリー・マップ・キャッシュ・ファイルにデータを保管することによって、JVM 間でクラス・データを共用することができます。複数の JVM がキャッシュを共用する場合、共用によって全体の仮想メモリーの使用量が削減されます。また、共用によって、キャッシュ作成後の JVM の起動時間も短縮されます。共用クラス・キャッシュは、どのアクティブな JVM からも独立しており、破棄されるまで存続します。

共用キャッシュには、以下を含むことができます。

クラス・データ共用の概要

クラス・データ共用は、メモリー・フットプリントを減らし、JVM 起動時間を改善するための透過的な手法です。|Java 6 |には、キャッシュの管理、分離、およびパフォーマンスに関連する機能が拡張され、新機能が導入されました。

クラス・データ共用の使用可能化

JVM の開始時、-Xshareclasses オプションを使用して、クラス・データ共用を使用可能にすることができます。 JVM は、既存のキャッシュに接続するか、キャッシュが存在しない場合は新規キャッシュを作成します。

JVM によってロードされるすべてのブートストラップおよびアプリケーション・クラスが、 デフォルトで共用されます。カスタム・クラス・ローダーは、アプリケーション・クラス・ローダーを継承している場合は 自動的にクラスを共用します。継承していない場合は、JVM で提供される Java ヘルパー API を使用して、そのキャッシュにアクセスする必要があります。(カスタム・クラス・ローダーの共用クラスへの適応を参照)

|JVM は、特定のメソッドの AOT (ahead-of-time) コンパイル・コードをキャッシュに格納します。これにより、後続の JVM の起動時間が短縮されます。AOT コンパイル・コードは、実際には JVM 間で共用されませんが、JVM 始動時のコンパイル時間を短縮する目的でキャッシュに入れられます。キャッシュに入れられる AOT コードの量は、ヒューリスティックに判別されます。キャッシュに格納されるメソッドを制御することはできませんが、AOT コードの格納に充てられるキャッシュ・スペースの容量の上限と下限を設定できます。また、AOT キャッシュを完全に使用不可に設定することもできます。 |詳しくは、クラス・データ共用の使用可能化と構成を参照してください。

キャッシュ・アクセス

|JVM は、読み取り/書き込みアクセス権限または読み取り専用アクセス権限でキャッシュにアクセスします。 読み取り/書き込みアクセス権限でキャッシュに接続する JVM は、このキャッシュを更新できます。キャッシュに対して同時に読み取り操作を実行できる JVM の数に制限はありません。これは、他の JVM がキャッシュに対して書き込み操作を実行している場合でも同様です。

実行時バイトコード変更を使用する場合は、注意が必要です。 詳しくは、実行時バイトコード変更を参照してください。

キャッシュの動的更新

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

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

共用クラス・キャッシュへのアクセスは、オペレーティング・システムの許可と Java セキュリティーの許可によって制限されます。クラス・データの共用を登録しているクラス・ローダーのみが、共用クラス・キャッシュを更新できます。

|キャッシュ・メモリーは、メモリー・ページ保護機能により偶発的/意図的な破損から保護されています。これは破損から完全に保護することを保証するものではありません。これは、JVM はページへの書き込み時にページの保護を解除する必要があるためです。キャッシュが変更されないことを保証する唯一の方法は、キャッシュを読み取り専用で開くことです。

Java SecurityManager がインストールされている場合、java.policy ファイルに SharedClassPermission 行を追加することによって、デフォルト・ブートストラップ、アプリケーション、および拡張クラス・ローダー以外のクラス・ローダーにクラス共用の許可を付与する必要があります。(SharedClassPermission の使用を参照) RuntimePermission 『createClassLoader』 は、新しいクラス・ローダーの作成を制限します。したがって、キャッシュへのアクセスも制限します。

キャッシュの存続期間

1 つのシステムに複数のキャッシュが存在することが可能で、それらは、 -Xshareclasses コマンドのサブオプションとして名前で指定されます。 JVM が一度に接続できるキャッシュは 1 つのみです。

始動時にデフォルトのキャッシュ・サイズを指定変更するには、-Xscmx<n><size> を使用します。キャッシュの存続期間中このサイズは変更されません。キャッシュは、-Xshareclasses コマンドのサブオプションを使用して明示的に破棄されるか、または キャッシュ・ファイルが手動で削除されるまで存在します。

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

キャッシュ・ユーティリティーはすべて、-Xshareclasses コマンドのサブオプションです。 クラス・データ共用の使用可能化と構成を参照するか、 -Xshareclasses:help を使用して、使用可能なサブオプションのリストを参照してください。

クラス・データ共用の使用可能化と構成

クラス・データ共用とキャッシュ管理ユーティリティーを制御するには、java ランチャーのコマンド行オプションを使用します。

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

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

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

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

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

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

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

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

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

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

クラス・データ共用を使用可能にするには、アプリケーション・コマンド行に -Xshareclasses[:name=<name>] を追加します。

JVM は、指定された名前の既存キャッシュに接続するか、その名前の新しいキャッシュを作成します。新しいキャッシュが作成された場合、キャッシュがフルになるまで、 ロードされるすべてのブートストラップおよびアプリケーション・クラスがそれに取り込まれます。 2 つ以上の JVM が同時に始動された場合、 それらすべてが同時にキャッシュにデータの取り込みを行います。

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

JVM が稼働している間のキャッシュ使用量について詳細にフィードバックするには、verbose サブオプションを使用します。 例えば、java -Xshareclasses:[name=<name>],verbose と指定します。

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

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

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

キャッシュがフルになると、verbose サブオプションを使用して、JVM のコマンド行にメッセージが出力されます。その後、フルのキャッシュを共用しているすべての JVM が、さらにクラスをプロセス・メモリーにロードします。フルのキャッシュ内のクラスは、依然として共用可能ですが、 フルのキャッシュは読み取り専用で、新しいクラスで更新することはできません。

パフォーマンスとメモリーの消費

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

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

重複クラスは、共用クラス・キャッシュ内で統合されます。例えば、myClasses.jar からロードされたクラス A と myOtherClasses.jar からロードされたクラス A (同じ内容) は、キャッシュに一度のみ保管されます。printAllStats ユーティリティーは、 重複したクラスの複数の項目を示します。各項目は同じクラスを指します。

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

クラス・データ共用を使用する際の考慮事項と制限

クラス・データ共用を製品にデプロイする場合と、開発環境でクラス・データ共用を使用する場合に検討すべき事項を示します。

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

理論上の最大キャッシュ・サイズは 2 GB です。指定できるキャッシュのサイズは、使用可能なディスク・スペースおよび使用可能な仮想アドレス・スペースの量によって制限されます。

キャッシュは、以下の要因によって制限されます。

実行時バイトコード変更

バイトコード・データを変更可能な JVM Tool Interface (JVMTI) エージェントを使用する JVM で、変更されたクラスを別の JVM と共用する場合は、modified=<modified_context> サブオプションを使用してください。

modified context (変更コンテキスト) は、実行される変更のタイプを記述する、ユーザー指定の記述子です。 変更コンテキストはキャッシュを区分し、同じコンテキストで実行されるすべての JVM が 1 つの区分を共用できるようにします。

この区分化により、変更されたバイトコードを使用しない JVM は、変更されたバイトコードを使用する JVM との間で 1 つのキャッシュを安全に共用することができます。指定された変更コンテキストを使用するすべての JVM は、予測可能であり反復可能な方法でクラスごとにバイトコードを変更することにより、 キャッシュに保管された変更クラスが別の JVM によってロードされるときに、期待どおりの変更値を持つようにする必要があります。共用クラス・キャッシュからロードされたクラスはエージェントによって再度変更されることはないため、変更は必ず予測可能です。

変更コンテキストなしで JVMTI エージェントを使用する場合も、JVM によりクラスを安全に共用できますが、パフォーマンスに若干の影響が出ます。 JVMTI エージェントで変更コンテキストを使用すれば、余分のチェックが不要になるため、パフォーマンスに影響はありません。java.net.URLClassLoader を拡張し、JVMTI を使用しないでロード時にバイトコードを変更するカスタム ClassLoader は、その変更されたバイトコードを自動的に保管しますが、キャッシュはそのバイトコードを変更されたものとして処理しません。同じキャッシュを共用するその他の VM は、変更されたクラスをロードします。JVMTI エージェントの場合と同じ方法で modified=<modification_context> サブオプションを使用して、キャッシュ内の変更されたバイトコードを区分できます。カスタムの ClassLoader で、クラスに対して予測不能なロード時変更を行う必要がある場合は、その ClassLoader でクラス・データの共用を試行してはいけません。

このトピックについて詳しくは、「Diagnostics Guide (英語)」を参照してください。

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

32 ビット JVM と 64 ビット JVM の間ではクラスを共用できません。キャッシュ情報を格納できる一時ディスク・スペースが必要です。キャッシュへのアクセス権限は、オペレーティング・システムによって施行されます。

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

共用クラス・キャッシュは、 システムに存在するキャッシュに関する識別情報を保管するためのディスク・スペースを必要とします。 この情報は、ユーザー・プロファイル・ディレクトリーに置かれます。 識別情報ディレクトリーが削除された場合、JVM はシステム上の共用クラスを識別できないため、 キャッシュを再作成する必要があります。

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

SharedClassPermission の使用

クラス・データ共用と併せて SecurityManager が使用され、 稼働中のアプリケーションで独自のクラス・ローダーが使用されている場合、 クラスを共用する前に、これらのクラス・ローダーにクラス共用の許可を付与する必要があります。

ClassLoader クラス名 (ワイルドカードを使用可) と、付与するアクセス権を決定する "read"、"write"、または "read,write" のいずれかを使用して、java.policy ファイルに共用クラスのアクセス権を追加します。 例えば、次のようにします。

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

に正しいアクセス権が設定されていないと、ClassLoader はクラスを共用できません。デフォルトのブートストラップ、アプリケーション、または拡張クラス・ローダーの許可は、変更できません。

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

java.net.URLClassLoader を拡張するクラス・ローダーは、変更することなくクラスを共用できます。java.net.URLClassLoader を拡張しないクラス・ローダーは、クラス・データを共用するように適応させる必要があります。

SecurityManager が使用される場合、すべてのカスタム・クラス・ローダーに、クラス共用の許可が付与される必要があります。SharedClassPermission の使用を参照してください。IBM は、カスタム・クラス・ローダーのさまざまなタイプに応じたいくつかの Java インターフェースを提供しています。 これにより、そのクラス・ローダーが、共用クラス・キャッシュでクラスを検出および保管することができます。これらのクラスは、com.ibm.oti.shared パッケージにあります。

このパッケージの Javadoc は、SDK で docs/content/apidoc ディレクトリーに提供されます。

これらのインターフェースの使用方法について詳しくは、「Diagnostics Guide (英語)」を参照してください。

Java Communications API (JavaComm) の使用

Java Communications (API) パッケージ (JavaComm) は、Runtime Environment for Windows で使用するために提供されているオプションのパッケージです。 JavaComm は、SDK あるいは Runtime Environment とは別に単独でインストールします。

JavaComm API により Java アプリケーションは、 ボイス・メール、ファクシミリ、およびスマートカードなどのテクノロジーに シリアルおよびパラレル・ポート通信を、プラットフォームに依存しないで実施することができます。

Java Communications API は、Electronic Industries Association (EIA)-232 (RS232) シリアル・ポートと米国電気電子学会 (IEEE) 1284 パラレル・ポートをサポートし、また、 IBM バージョン 6 Runtime Environment の入ったシステムに対応しています。

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

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

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

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

  1. Java Communications API 圧縮ファイル ibm-javacomm-3.0-0.0-win-i386.zip, を、SDK または Runtime Environment がインストールされているディレクトリーに格納します。デフォルト・ ディレクトリーにインストールした場合、これは C:¥Program Files¥IBM¥Java60¥ になります。
  2. 圧縮ファイルを解凍します。 Java Communications API が、既存のディレクトリー内のサブディレクトリーに解凍されます。
  3. |javacomm ファイルを、ご使用の SDK 内の適切なディレクトリーにコピーします。 | |
      |
    1. lib¥win32com.dllを jre¥bin¥ ディレクトリーにコピーします。
    2. |
    3. jar\comm.jar を jre\lib\ext\ ディレクトリーにコピーします。
    4. |
    5. lib\javax.comm.properties を jre\lib\ ディレクトリーにコピーします。
    デフォルトでは、SDK は C:¥Program Files¥IBM¥Java60¥ ディレクトリーにインストールされます。
  4. |comm.jar をクラスパスに追加します。これは、JRE インストールでは必須ではありません。 | |
      |
    • クラスパスが定義されていない場合: set CLASSPATH=¥jre¥lib¥ext¥comm.jar
    • |
    • クラスパスが定義されている場合: set CLASSPATH=¥jre¥lib¥ext¥comm.jar;%classpath%

javax.comm.properties ファイル内のデバイスの指定

javax.comm.properties ファイルによって、Java Communications API で使用可能にするデバイスの接頭部および、それらのデバイスがパラレルかシリアルかを指定することが可能です。ポート番号は、すべてのデバイスに順に割り振られます。

例えば、/dev/ttyS=PORT_SERIAL と指定して、2 つのデバイス、/dev/ttyS0 および /dev/ttyS1 が存在する場合、それらのデバイスは、COM1 および COM2 に割り振られます。

USB-シリアル・コネクターを使用する場合は、javax.comm.properties ファイルの /dev/ttyUSB=PORT_SERIAL 行のコメントを外します。デバイス /dev/ttyUSB0 および /dev/ttyUSB1 が存在するが、すでに COM1 および COM2 が定義済みの場合、これらの USB-シリアル・デバイスは COM3 および COM4 に割り振られます。

Java Communications API での印刷に関する制限

Java Communications API を使用して印刷をするときは、プリンターで「用紙送り」、「継続」、または類似したボタンを押す必要があります。

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

Java Communications API をアンインストールするには、Runtime Environment をインストールしたディレクトリーから以下のファイルを削除します。

Runtime Environment は、デフォルトで C:¥Program Files¥IBM¥Java60¥ ディレクトリーにインストールされます。

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

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

http://java.sun.com/products/javacomm/

独立系ソフトウェア・ベンダーのサービスおよびサポート

サービスの連絡先:

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

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

アクセシビリティー

この SDK および Runtime Environment で提供されるこのユーザー・ガイドは、スクリーン・リーダーを使用してテストしてあります。

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

キーボード・ナビゲーションが必要な場合は、http://www.ibm.com/developerworks/java/jdk/additional/ の『Swing Key Bindings』にある Swing アプリケーション用の便利なキー・ストロークの説明を参照してください。

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

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

Web Start のアクセシビリティー

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

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

セキュリティーに関する一般注意

JCE 無制限管轄ポリシー・ファイルは、http://www.ibm.com/developerworks/java/jdk/security/index.html から入手できます。 IBM セキュリティー・パッケージ JCE、JCEFIPS、JSSE2、JSSEFIPS、JGSS、JAAS、およびハードウェア暗号方式に関する文書も、 この Web サイトで入手できます。

本書に関するご意見

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

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

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

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

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

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

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

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

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

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

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

付録B. 既知の制限

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

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

サポート対象ロケールでのフォント問題

IBM 32-bit SDK for Windows, v6 は、以下のロケールをサポートします。

ただし、これらのロケールのフォントは、AWT コンポーネントでは機能しない可能性があります。

IPv6 によるソケットの使用

IBM 32-bit SDK for Windows, v6 は、IPv6 をサポートします。ただし、現在の Windowsにおける IPv6 のサポートはデュアル・スタックではないため、SDK は、IPv6 対応システムでデュアル・スタックの動作をエミュレートします。ご使用の Java アプリケーションは、エミュレーションの性質から、最大 2 倍の数のソケットを使用する可能性があります。 このエミュレーションを使用不可にするには、システム・プロパティー java.net.preferIPv4Stacktrue に設定して SDK の IPv6 サポートを使用不可にしてください。

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

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

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

Rhino Javascript エンジンの使用不可

Mozilla Rhino Javascript エンジンは、ライセンス交付の問題があるため、IBM SDK for Java には組み込まれていません。IBM SDK for Java で Rhino Javascript エンジンを使用するには、https://scripting.dev.java.net/ から jsr223 スクリプト・エンジンをダウンロードし、Mozilla Web サイト (http://www.mozilla.org/rhino/) から Rhino Javascript エンジンをダウンロードしてください。

IME (Input Method Editor)

IME を使って作業をしている時は、スクリーン上のワークスペースで漢字入力以外の操作をする前に、漢字入力と候補の選択を終わらせておくようにお勧めします。

IME を使用して AWT TextArea 内にテキストを入力する場合、 そのテキストを確定する にアプリケーションのウィンドウをサイズ変更すると、 そのテキストは自動的に確定されます。

DSA 鍵ペアの生成に時間がかかる

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

パーソナル・ファイアウォール

パーソナル・ファイアウォールが原因で、 Windows NIO コードに問題が生じ、その結果、特定の操作が失敗することがあります。例えば、メソッド呼び出しの Selector.open() は、「java.io.IOException: ループバック接続を確立できません (java.io.IOException: Unable to establish loopback connection)」をスローし、「java.net.ConnectException: 接続が拒否されました: connect (java.net.ConnectException: Connection refused: connect)」の原因になります。この例外は、ファイアウォールでブロックされているポートに接続する オペレーティング・システムによって起こります。 JVM は、オペレーティング・システムに別のポート番号を選択するように要求して、 接続操作を再試行します。 何度か再試行しても接続できない場合は、ConnectException がスローされます。

この例外が発生したら、システム・プロパティー java.nio.debug=pipe を設定して、どのポート番号がブロックされているかを確認してください。

ファイル・ハンドルの上限

Windows 2000 および XP では、同時にオープンできるファイル数のデフォルト値が小さすぎるため、入出力集中のアプリケーションで問題が起こります。 この制限を修正するには、ファイル <windows>¥system32¥CONFIG.NT を編集し、以下の値を設定します。

files=200
buffers=60

ここで、<windows> は Windows がインストールされたディレクトリーです。

DirectDraw およびマウス・ポインターの問題

Windows 2000 において、32 ビット・カラー階調で、JVM の DirectDraw メカニズムが、マウス・ポインターの下の領域を再描画しません。その結果として、メニュー上にマウスがあった後、そこにグレーまたは黒の正方形が表示されます。 次善策としては、ダイレクト・ドローをオフに切り替える (-Dsun.java2d.noddraw) か、または画面カラー解像度を他の値 (256 色など) に変更します。

NIO 接続問題

NIO SocketChannel finishConnect() 呼び出しは、true (チャネルが接続された) または false (接続処理が未完了) を戻すか、例外をスローする可能性があります。 Windows 2000 で非ブロッキング接続を使用する場合、前の Java select() 呼び出しでチャネルでの処理準備が完了していることが示された後でも、FALSE が戻される可能性があります。

メイン・スレッドのスタック範囲

Java メイン・スレッド (原始スレッドとも呼ばれる) のスタック範囲は、 実行時に変更できません。メイン・スレッドのサイズは、256 KB の固定で、これはパフォーマンス上の理由から最適な値として判断されたものです。 -Xss オプションを使用すると、 メイン・スレッド以外のスレッドについてのみ、スタック範囲を変更できます。 メイン・スレッドは、他のスレッドよりスタック・オーバーフローが発生しやすいため、過重な再帰的計算があるプログラムには使用しないでください。

DBCS 文字

JTextArea、JTextField、または JFileChooser に DBCS 文字を入力中に、一部の中国語 IME (特に、Chinese Internal Code および Zhengma) から Intelligent ABC IME に切り替えると、メモリー・ダンプが生成される場合があります。

チェコ語のインストール

チェコ語ユーザーの場合、InstallShield の言語選択パネルで、 本来なら翻訳されないインストールにおいて、翻訳された 1 つの項目が示されます。この制限は InstallShield に起因するものです。このストリングは、コード・ページに基づいてオペレーティング・システムから取得されます。 ポーランド語 (インストールが翻訳される) とチェコ語のコード・ページは両方とも 1250 であるため、 InstallShield は、両方の言語についてシステムから言語リストを取得しようとするため、 このストリングが言語リストに入ります。

中国語 (繁体字) と more コマンド

中国語 (繁体字) を使用する場合、Java アプリケーションからの出力を直接 more コマンドにパイプ接続しないでください。代わりに、その出力を一時ファイルに送って、そのファイルを別に表示してください。

カタロニア語ユーザーのアクセントの乱れ

カタロニア語ユーザーの場合、アクセント記号付きの大文字が破壊されないようにするために、 Lucida Console フォントを使用してください。 これが影響するのは、Windows 2000 のユーザーのみです。

GTK Look and Feel と NullPointerException

DBCS 環境のみ

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

Unicode Shift_JIS コード・ページ別名

日本語ユーザーのみ

Shift_JIS の Unicode コード・ページ別名 「¥u30b7¥u30d5¥u30c8¥u7b26¥u53f7¥u5316¥u8868¥u73fe」は削除されています。アプリケーションでこのコード・ページを使用する場合は、Shift_JIS で置き換えてください。

特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。 本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。

本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。

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

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

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

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

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

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

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

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

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

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

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

商標

IBM、AIX、developerWorks、eServer、iSeries、MVS、POWER4、 POWER5+、 PowerPC、pSeries、System i、System p、System z、WebSphere、System z9、z/OS、および zSeries は、International Business Machines Corporation の米国およびその他の国における商標です。

Intel は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。

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

Microsoft、Windows および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。

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

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