Java Platform Standard Edition

コア・ライブラリ

リリース9

E90922-01(原本部品番号:E74190-02)

2017年9月

Java Platform, Standard Editionコア・ライブラリ, リリース9

E90922-01

Copyright © 2017, Oracle and/or its affiliates.  All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアはさまざまな情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 非推奨の拡張

- JDKでの非推奨

- APIを非推奨とする方法

- 通知および警告

- jdeprscanの実行

2 XMLカタログAPI

- XMLカタログAPIの目的

- XMLカタログAPIのインタフェース

- XMLカタログAPIの使用

- システム参照

- パブリック参照

- URI参照

- Java XMLプロセッサ・サポート

- カタログ・サポートの有効化

- XMLプロセッサでのカタログの使用

- リゾルバのコール順序

- エラーの検出

3 不変のリスト、セットおよびマップの作成

- ユースケース

- 構文

- 不変リストの静的ファクトリ・メソッド

- 不変セットの静的ファクトリ・メソッド

- 不変マップの静的ファクトリ・メソッド

- ランダム化された反復順序

- 不変性について

- 領域効率

4 プロセスAPI

- プロセスAPIのクラスとインタフェース

- ProcessBuilderクラス

- Processクラス

- ProcessHandleインタフェース

- ProcessHandle.Infoインタフェース

- プロセスの作成

- プロセスに関する情報の取得

- プロセスからの出力のリダイレクト

- ストリームでのプロセスのフィルタリング

- プロセス終了時のonExitメソッドを使用したプロセスの処理

- 機密プロセス情報へのアクセスの制御

はじめに

このガイドでは、Javaコア・ライブラリに関する情報を示します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 非推奨の拡張

JDK 9では、APIが今後削除されるかどうかを含めて、非推奨の意味のセマンティクスを明確にしています。

ライブラリの保守担当者である場合は、更新された非推奨構文を使用して、ライブラリで提供されるAPIのステータスをライブラリのユーザーに通知できます。

ライブラリまたはアプリケーションの開発者である場合は、jdeprscanツールを使用して、アプリケーションまたはライブラリで使用されている非推奨のJDK API要素を探すことができます。

トピック

- JDKでの非推奨

- APIを非推奨とする方法

- 通知および警告

- jdeprscanの実行

JDKでの非推奨

非推奨は、ライブラリのコンシューマに非推奨APIからコードを移行する必要があることを示す通知です。

JDKでは、次を含む様々な理由でAPIが非推奨になりました。

- APIが危険である(Thread.stopメソッドなど)。

- 単純に名前が変更された(例: AWT Component.show/hideがsetVisibleに置き換わった)。

- より新しくよりよいAPIをかわりに使用できる。

- 非推奨のAPIが削除される予定である。

以前のリリースでは、非推奨になったAPIが実際に削除されたことはありません。JDK 9では、削除対象のAPIが非推奨としてマークされます。これは、JDKプラットフォームの次期リリースでAPIが削除されることを示します。アプリケーションまたはライブラリでこれらのAPIを使用している場合は、すぐに移行することを計画する必要があります。

JDK 9リリースの非推奨APIのリストは、API仕様の「非推奨API」のページを参照してください。

APIを非推奨とする方法

APIを非推奨にするには、@Deprecated注釈および@deprecated Javadocタグという2つの異なるメカニズムを使用する必要があります。

APIをマークする@Deprecated注釈は、クラス・ファイルに記録され、ランタイムに使用されます。これにより、javacおよびjdeprscanなどの様々なツールで非推奨APIを検出し使用状況のフラグを付けられるようになります。@deprecated Javadocタグは、非推奨になった理由を説明したり代替APIを提示するために、非推奨APIのドキュメントで使用されます。

大文字と小文字に注意してください。注釈は大文字のDで始まり、Javadocタグは小文字のdで始まります。

@Deprecated注釈の使用

非推奨を示すには、モジュール、クラス、メソッドまたはメンバーの宣言の前に@Deprecatedを置きます。注釈にはこれらの要素が含まれます。

- @Deprecated(since="<version>")

- <version>はAPIが非推奨になったときのバージョンです。これは情報提供を目的としています。デフォルトは空の文字列("")です。

- @Deprecated(forRemoval=<boolean>)

- forRemoval=trueは、APIが今後のリリースで削除されることを示します。

- forRemoval=falseは、今後はコードでこのAPIを使用しないことが推奨されますが、現時点でAPIが削除される予定はないことを示します。これはデフォルト値です。

例: @Deprecated(since="9", forRemoval=true)

@Deprecated注釈を使用すると、プログラム要素が表示される場所にかかわらず、Javadocによって生成されたドキュメントに次のいずれかのマークが付きます。

- 推奨されていません。

- 非推奨、削除予定: このAPI要素は将来のバージョンで削除予定です。

javadocツールによって、非推奨APIのリストが含まれるdeprecated-list.htmlという名前のページが生成され、そのページへのリンクがナビゲーション・バーに追加されます。

次に示すのは@Deprecated注釈の簡単な使用例で、java.lang.Threadクラスからの抜粋です。

public class Thread implements Runnable {
...
@Deprecated(since="1.2")
public final void stop() {
...
}
...

非推奨のセマンティクス

開発者は@Deprecated注釈の2つの要素を使用して、エクスポートしたAPIの非推奨の意味を明確に示すことができます。

JDKプラットフォームの場合:

- @Deprecated(forRemoval=true)は、APIがJDKプラットフォームの今後のリリースで削除されることを示します。

- @Deprecated(since="<version>")には、JDK 9以降に非推奨になったAPI要素がいつ非推奨になったかを示すJDKバージョン文字列が含まれています。

ライブラリを保守し独自のAPIを作成している場合、@Deprecated注釈を使用していることが想定されます。APIの削除に関するポリシーについて決定および周知する必要があります。たとえば、6週間ごとに新しいライブラリをリリースする場合、APIを削除対象として非推奨にしても、数か月の間は削除せずに、顧客が移行するための時間を用意することができます。

@deprecated Javadocタグの使用

非推奨プログラム要素のjavadocコメントで@deprecatedタグを使用して、今後の使用は(引き続き動作するとしても)推奨されないことを示します。このタグは、すべてのクラス、メソッドまたはフィールド・ドキュメントのコメントで有効です。@deprecatedタグの後にはスペースまたは改行を置く必要があります。@deprecatedタグに続く段落では、非推奨になった理由を説明し、かわりに使用できるものを提示します。同じ機能を持つ新しいバージョンを示すテキストを@linkタグでマークします。

@deprecatedタグが検出されると、javadocツールによって、@deprecatedタグに続くテキストが説明の前に移動され、その前に警告が置かれます。たとえば、次のソースによって、

/**
* ...
* @deprecated  This method does not properly convert bytes into
* characters.  As of JDK 1.1, the preferred way to do this is via the
* {@code String} constructors that take a {@link
* java.nio.charset.Charset}, charset name, or that use the platform's
* default charset.
* ...
*/
@Deprecated(since="1.1")
public String(byte ascii[], int hibyte) {
...

次の出力が生成されます。

@Deprecated(since="1.1")
public String(byte[] ascii,
int hibyte)
Deprecated. This method does not properly convert bytes into characters. As of
JDK 1.1, the preferred way to do this is via the String constructors that take a
Charset, charset name, or that use the platform's default charset.

対応する@Deprecated注釈を使用せずに@deprecated Javadocタグを使用した場合は、警告が生成されます。

通知および警告

APIが非推奨になった場合は、開発者に通知する必要があります。非推奨APIによって、コードに問題が発生したり、これが後に削除された場合はランタイムにエラーが発生する可能性があります。

Javaコンパイラでは非推奨APIに関する警告が生成されます。警告に関する詳細な情報を生成するオプションがあり、また非推奨の警告を抑制することもできます。

コンパイラの非推奨警告

非推奨がforRemoval=falseである場合、Javaコンパイラでは「通常の非推奨警告」が生成されます。非推奨がforRemoval=trueである場合、コンパイラでは「削除警告」が生成されます。

2種類の警告は個別の-Xlintフラグ(-Xlint:deprecationおよび-Xlint:removal)によって制御されます。デフォルトではjavac -Xlint:removalオプションが有効であり、削除警告が表示されます。

また、警告は("–"を付けて)個別にオフにできます(-Xlint:-deprecationおよび-Xlint:-removal)。

通常の非推奨警告の例を次に示します。

$ javac src/example/DeprecationExample.java
Note: src/example/DeprecationExample.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

javac -Xlint:deprecationオプションを使用して、どのAPIが非推奨になっているかを示します。

$ javac -Xlint:deprecation src/example/DeprecationExample.java
src/example/DeprecationExample.java:12: warning: [deprecation] getSelectedValues() in JList has been deprecated
Object[] values = jlist.getSelectedValues();
^
1 warning

削除警告の例を次に示します。

public class RemovalExample {
public static void main(String[] args) {
System.runFinalizersOnExit(true);
}
}
$ javac RemovalExample.java
RemovalExample.java:3: warning: [removal] runFinalizersOnExit(boolean) in System
has been deprecated and marked for removal
System.runFinalizersOnExit(true);
^
1 warning
==========

非推奨警告の抑制

javac -Xlintオプションは、javacの特定の実行でコンパイルされたすべてのファイルの警告を制御します。今後は表示しない警告を生成するソース・コードの特定の場所を識別しているとします。@SuppressWarnings注釈を使用して、そのコードがコンパイルされるときはいつでも警告を抑制できます。非推奨APIを使用するクラス、メソッド、フィールドまたはローカル変数の宣言に@SuppressWarnings注釈を配置します。

@SuppressWarningsオプションを次に示します。

- @SuppressWarnings("deprecation") - 通常の非推奨警告のみを抑制します。

- @SuppressWarnings("removal") - 削除警告のみを抑制します。

- @SuppressWarnings({"deprecation","removal"}) - 両方のタイプの警告を抑制します。

警告の抑制の例を次に示します。

@SuppressWarnings("deprecation")
Object[] values = jlist.getSelectedValues();

@SuppressWarnings注釈を使用すると、コマンドラインで警告が有効化されている場合も、この行の警告は発行されません。

jdeprscanの実行

jdeprscanは、アプリケーションでの非推奨JDK API要素の使用をレポートする静的分析ツールです。jdeprscanを実行して、コンパイル済クラス・ファイルまたはjarファイルに発生する可能性がある問題を識別しやすくします。

コンパイラの通知から非推奨のJDK APIを見つけることができます。ただし、JDKのリリースごとに再コンパイルしない場合、警告が抑制されている場合、またはバイナリ・アーティファクトとして配布されるサードパーティのライブラリに依存している場合は、jdeprscanを実行する必要があります。

非推奨APIがJDKから削除される前に、そのAPIへの依存性を発見することが重要です。現在のJDKリリースで、削除される非推奨APIをバイナリで使用しており、再コンパイルしない場合は、通知を受け取りません。今後のJDKリリースでAPIが削除されると、バイナリはランタイムに失敗します。jdeprscanによって、APIが削除される前に、現時点でそれが使用されていることが検出されます。

ツールを実行するための完全な構文と出力の解析方法は、Java Platform, Standard Editionツール・リファレンスのjdeprscanに関する項を参照してください。

2 XMLカタログAPI

XMLカタログAPIを使用してローカルXMLカタログを実装します。

Java SE 9では、新しいXMLカタログAPIが導入され、Organization for the Advancement of Structured Information Standards (OASIS) XMLカタログ、OASIS標準V1.1がサポートされるようになりました。 Oracle JDK 9コア・ライブラリ・ガイドのこの章では、API、Java XMLによるサポート、および使用パターンについて説明します。

XMLカタログAPIは、ローカル・カタログを実装するための単純なAPIであり、JDK XMLプロセッサによるサポートによってプロセッサや環境全体の構成が容易になり、その機能を活用することができます。

カタログ作成の詳細の学習

カタログ作成の詳細は、カタログ標準に関する項を参照してください。一部のLinuxディストリビューションの/etc/xml/catalogディレクトリの下にあるXMLカタログもまた、ローカル・カタログを作成するための参考になります。

XMLカタログAPIの目的

XMLカタログAPIとJava XMLプロセッサには、外部リソースの管理を容易にするための、開発者およびシステム管理者向けのオプションが用意されています。

XMLカタログAPIは、外部リソースが原因で発生する問題に対処するために設計された標準の、OASIS XMLカタログv1.1の実装を提供します。

外部リソースが原因で発生する問題

XML、XSDおよびXSLのドキュメントには、Java XMLプロセッサがドキュメントを処理するために取得する必要がある、外部リソースへの参照が含まれている可能性があります。外部リソースによってアプリケーションまたはシステムに問題が発生する場合があります。カタログAPIとJava XMLプロセッサには、これらの外部リソースの管理を容易にするための、開発者およびシステム管理者向けのオプションが用意されています。

外部リソースによって、アプリケーションまたはシステムの次の領域に問題が発生する場合があります。

- 可用性。リソースがリモートにある場合、XMLプロセッサがリモート・サーバーに接続できる必要があります。接続性が問題となることはまれですが、アプリケーションの安定性に影響する要因になります。接続数が多すぎると、リソースを保持しているサーバーに障害が発生する恐れがあり(詳細な文書化によってW3Cのサーバーへの過剰なDTDトラフィックが発生するなど)、アプリケーションにも影響が及ぶ可能性があります。XMLカタログAPIを使用してこの問題を解決する例は、「スキーマ検証でのカタログの使用」を参照してください。

- パフォーマンス。接続性が問題になることはほとんどありませんが、リモート・フェッチによってアプリケーションのパフォーマンスに問題が生じることがあります。さらに、同じシステム上に同じソースの解決を試行するアプリケーションが複数存在する場合があり、これによってシステム・リソースに無駄が生じます。

- セキュリティ。リモート接続を許可すると、アプリケーションで信頼されないXMLソースが処理された場合にセキュリティ・リスクが発生します。

- 管理の容易性。システムで多数のXMLドキュメントを処理する場合、外部参照ドキュメントが(ローカルかリモートかに関係なく)保守上の問題になる可能性があります。

外部リソースが原因で発生する問題にXMLカタログAPIで対応する方法

XMLカタログAPIとJava XMLプロセッサには、外部リソースの管理を容易にするための、開発者およびシステム管理者向けのオプションが用意されています。

- アプリケーション開発者 - アプリケーションのすべての外部参照のローカル・カタログを作成し、カタログAPIを使用して参照をアプリケーション用に解決します。これによって、リモート接続が回避されるだけでなく、これらのリソースの管理が容易になります。

- システム管理者 - システムのローカル・カタログを確立し、Java VMがそのカタログをポイントするように構成できます。次に、システム上のすべてのアプリケーションがアプリケーションのコードを変更することなく(Java SE 9と互換性があることを想定)、同じカタログを共有します。カタログを確立するために、一部のLinuxディストリビューションに含まれるカタログなどの既存のカタログを使用できます。

XMLカタログAPIのインタフェース

XMLカタログAPIにアクセスするは、XMLカタログAPIのインタフェースを使用します。

XMLカタログAPIのインタフェース

XMLカタログAPIでは、次のインタフェースが定義されています。

- Catalogインタフェースは、XMLカタログ、OASIS標準V1.1 (2005年10月7日)で定義されているとおり、エンティティ・カタログを表します。Catalogオブジェクトは不変です。Catalogオブジェクトを作成したら、これを使用してsystem、public、またはuriエントリ内の一致を探します。カスタム・リゾルバを実装すると、カタログを使用してローカル・リソースを検索するのが便利であることがわかります。

- CatalogFeaturesクラスには、javax.xml.catalog.files、javax.xml.catalog.defer、javax.xml.catalog.prefer、およびjavax.xml.catalog.resolveなどの、カタログAPIがサポートするすべての機能とプロパティが保持されています。

- CatalogManagerクラスは、XMLカタログおよびカタログ・リゾルバの作成を管理します。

- CatalogResolverインタフェースは、スキーマ検証で使用するSAX EntityResolver、StAX XMLResolver、DOM LS LSResourceResolver、および変換URIResolverを実装するカタログ・リゾルバです。インタフェースではカタログを使用して外部参照が解決されます。

CatalogFeaturesクラスの詳細

カタログ機能はCatalogFeaturesクラスにまとめて定義されています。機能はAPIレベルとシステム・レベルで定義されており、API、システム・プロパティおよびJAXPプロパティを使用して設定できます。APIを使用して機能を設定するには、CatalogFeaturesクラスを使用します。

次のコードでは、javax.xml.catalog.resolveが"continue"に設定されるため、CatalogResolverによって一致が見つからなくても処理は続行します。

CatalogFeatures f = CatalogFeatures.builder().with(Feature.RESOLVE, "continue").build();
この"continue"機能をシステム全体に設定するには、JavaコマンドラインまたはSystem.setPropertyメソッドを使用します。

System.setProperty(Feature.RESOLVE.getPropertyName(), "continue");
この"continue"機能をJVMインスタンス全体に設定するには、jaxp.propertiesファイルに次の行を入力します。

javax.xml.catalog.resolve = "continue"
resolveプロパティと、preferおよびdeferの各プロパティは、カタログの属性またはカタログ・ファイルのグループ・エンティティとして設定できます。たとえば、次のカタログでは、カタログ・エントリにresolve属性が値"continue"とともに設定されており、このカタログ内に一致が見つからない場合に処理を続行することをプロセッサに指示しています。属性は、次のようにgroupエントリでも設定できます。

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" resolve="continue" xml:base="http://local/base/dtd/">
<group resolve="continue">
<system systemId="http://remote/dtd/alice/docAlice.dtd" uri="http://local/dtd/docAliceSys.dtd" />
</group>
</catalog>
より狭い範囲に設定されたプロパティは広い範囲に設定された属性をオーバーライドします。そのため、APIを使用して設定されたプロパティが常に優先されます。

XMLカタログAPIの使用

XMLカタログ標準の様々なエントリ・タイプを使用して、XMLソース・ドキュメントのDTD、エンティティおよび代替URI参照を解決します。

XMLカタログ標準では、数多くのエントリ・タイプが定義されています。そのうち、system、rewriteSystemおよびsystemSuffixの各エントリを含むシステム・エントリはXMLソース・ドキュメントのDTDおよびエンティティ参照を解決するために使用され、uriエントリは代替URI参照用です。

システム参照

CatalogResolverオブジェクトを使用してローカル・リソースを検索します。

ローカル・リソースの検索

次の例では、example.dtdプロパティへの参照を含むXMLファイルを使用して、systemエントリを使用してローカル・リソースを検索するためにCatalogResolverオブジェクトを使用する方法を示しています。

<?xml version="1.0"?>
<!DOCTYPE  catalogtest  PUBLIC  "-//OPENJDK//XML CATALOG DTD//1.0"
"http://openjdk.java.net/xml/catalog/dtd/example.dtd">

<catalogtest>
Test &example; entry
</catalogtest>

example.dtdにはエンティティ"example"が定義されています。

<!ENTITY example "system">

XMLにexample.dtdへのURIが存在している必要はありません。一意の識別子を指定するのは、CatalogResolverオブジェクトでローカル・リソースを検索するのが目的です。これを行うには、catalog.xmlというカタログ・エントリ・ファイルにローカル・リソースを参照するためのsystemエントリを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="http://openjdk.java.net/xml/catalog/dtd/example.dtd" uri="example.dtd"/>
</catalog>

このカタログとsystemエントリを使用して行うことは、デフォルトのCatalogFeaturesオブジェクトを取得し、カタログ・ファイルへのURIを設定してCatalogResolverオブジェクトを作成するだけです。

CatalogResolver cr = CatalogManager.catalogResolver(CatalogFeatures.defaults(), catalogUri);

catalogUriは有効なURIである必要があります。次に例を示します。

URI.create("file:///users/auser/catalog/catalog.xml")
CatalogResolverオブジェクトをJDK XMLリゾルバとして使用できるようになりました。次の例では、SAX EntityResolverとして使用されています。

SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
XMLReader reader = factory.newSAXParser().getXMLReader();
reader.setEntityResolver(cr);

例ではシステム識別子に絶対URIが指定されていることに注意してください。これにより、リゾルバがカタログのsystemエントリに完全に一致するsystemIdを検索することが容易になります。

XMLのsystem識別子が相対である場合は、XMLプロセッサで指定のベースURIまたはソース・ファイルのURIを使用して絶対化する必要があるため、一致プロセスが複雑になります。その場合、システム・エントリのsystemIdが予期される絶対URIと一致する必要があります。より簡単に解決するには、次のようにsystemSuffixエントリを使用します。

<systemSuffix systemIdSuffix="example.dtd" uri="example.dtd">

systemSuffixエントリは、XMLソースのexample.dtdで終わる任意の参照と一致し、それをuri属性に指定されているとおりにローカルのexample.dtdファイルに解決します。systemIdが一意または正しい参照になるように、詳細を追加します。たとえば、systemIdSuffixをxml/catalog/dtd/example.dtdに設定するか、XMLソース・ファイルとsystemSuffixエントリの両方でidが一意に一致するように名前を変更します(例: my_example.dtd)。

systemエントリのURIには、絶対URIまたは相対URIを指定できます。外部リソースの場所が固定されている場合は、絶対URIの方が一意性が保証されます。外部リソースがカタログ・エントリ・ファイルまたはアプリケーションに対して相対的な位置にある場合は、相対URIの方が効果的であり、アプリケーションのデプロイメントでインストール場所を意識する必要がありません。そのような相対URIは、ベースURIまたはカタログ・ファイルのURI (ベースURIが指定されていない場合)を使用して解決されます。前述の例では、example.dtdがカタログ・ファイルと同じディレクトリに置かれていることを想定しています。

パブリック参照

systemエントリのかわりにpublicエントリを使用して目的のリソースを検索します。

目的のリソースにsystemエントリが一致せず、PREFERプロパティがpublicと一致するように指定されている場合は、publicエントリを使用してsystemエントリと同じことを行えます。PREFERプロパティのデフォルト設定はpublicです。

パブリック・エントリの使用

解析済XMLファイルのDTD参照に"-//OPENJDK//XML CATALOG DTD//1.0"のようなパブリック識別子が含まれている場合は、カタログ・エントリ・ファイルのpublicエントリを次のように記述できます。

<public publicId="-//OPENJDK//XML CATALOG DTD//1.0" uri="example.dtd"/>

CatalogResolverオブジェクトを作成してこのエントリ・ファイルと使用する場合、example.dtdはpublicIdプロパティを使用して解決されます。CatalogResolverオブジェクトの作成例は、「システム参照」を参照してください。

URI参照

uriエントリを使用して目的のリソースを検索します。

uri、rewriteURIおよびuriSuffixなどのURIタイプのエントリは、システム・タイプのエントリと同じように使用できます。

URIエントリの使用

XMLカタログ標準では、systemタイプのエントリにはDTD参照の解決、uriタイプのエントリにはその他すべてのプリファレンスが指定されていますが、Java XMLカタログAPIではそのような区別がありません。これは、XMLResolverおよびLSResourceResolverなどの既存のJava XMLリゾルバの仕様ではプリファレンスを指定しないためです。uri、rewriteURIおよびuriSuffixなどのuriタイプのエントリは、systemタイプのエントリと同じように使用できます。uri要素は、代替URI参照とURI参照を関連付けるために定義されます。system参照の場合、これはsystemIdプロパティです。

そのため、systemエントリは一般的にはDTD参照に使用されますが、次の例のようにsystemエントリをuriエントリに置き換えることができます。

<system systemId="http://openjdk.java.net/xml/catalog/dtd/example.dtd" uri="example.dtd"/>

uriエントリの例を次に示します。

<uri name="http://openjdk.java.net/xml/catalog/dtd/example.dtd" uri="example.dtd"/>

systemエントリがDTDのために使用されるのに対して、uriエントリはXSDおよびXSLのインポートとインクルードなどのURI参照に使用されます。次の例では、XSLインポートの解決にuriエントリが使用されています。

「XMLカタログAPI」で説明しているように、XMLカタログAPIでは、EntityResolver、XMLResolver、URIResolver、LSResolverなどのJava XMLリゾルバを拡張するCatalogResolverインタフェースが定義されています。そのため、CatalogResolverオブジェクトは、SAX、DOM、StAX、スキーマ検証およびXSLT変換で使用できます。次のコードでは、CatalogResolverオブジェクトがデフォルトの機能設定で作成されます。

CatalogResolver cr = CatalogManager.catalogResolver(CatalogFeatures.defaults(), catalogUri);

コードでは次に、このCatalogResolverオブジェクトをURIResolverオブジェクトが予期されるTransformerFactoryクラスに登録します。

TransformerFactory factory = TransformerFactory.newInstance();
factory.setURIResolver(cr);

かわりに、コードでCatalogResolverオブジェクトをTransformerオブジェクトに登録することもできます。

Transformer transformer = factory.newTransformer(xslSource);
transformer.setURIResolver(cur);

XSLソース・ファイルに、xslImport.xslファイルをXSLソースにインポートするためのimport要素が含まれているとします。

<xsl:import href="pathto/xslImport.xsl" />
import参照をインポート・ファイルが実際にある場所に解決するには、Transformerオブジェクトを作成する前にCatalogResolverオブジェクトがTransformerFactoryクラスに設定されており、カタログ・エントリ・ファイルに次のようなuriエントリが追加されている必要があります。

<uri name="pathto/xslImport.xsl" uri="xslImport.xsl"/>

システム参照における絶対URIと相対URI、およびsystemSuffixエントリまたはuriSuffixエントリの使用に関する検討は、uriエントリにも当てはまります。

Java XMLプロセッサ・サポート

XMLカタログ機能を標準Java XMLプロセッサと使用します。

XMLカタログ機能は、SAXおよびDOM (javax.xml.parsers)、StAXパーサー(javax.xml.stream)、スキーマ検証(javax.xml.validation)、XML変換(javax.xml.transform)などのJava XMLプロセッサを使用してサポートされます。

これは、XMLプロセッサの外部にCatalogResolverオブジェクトを作成する必要がないことを意味します。カタログ・ファイルは、Java XMLプロセッサに直接登録するか、システム・プロパティを使用して指定するか、jaxp.propertiesファイルに指定できます。XMLプロセッサによって自動的にカタログを使用したマッピングが実行されます。

カタログ・サポートの有効化

プロセッサでのXMLカタログ機能のサポートを有効化するには、USE_CATALOG機能がtrueに設定されており、少なくとも1つのカタログ・エントリ・ファイルが指定されている必要があります。

USE_CATALOG

Java XMLプロセッサによって、XMLカタログ機能がUSE_CATALOG機能の値に基づいてサポートされるかどうかが決定されます。デフォルトでは、USE_CATALOGはすべてのJDK XMLプロセッサに対してtrueに設定されています。Java XMLはさらにカタログ・ファイルの使用可能性を確認し、USE_CATALOG機能がtrueでカタログが使用可能である場合にのみ、XMLカタログAPIの使用を試行します。

USE_CATALOG機能は、XMLカタログAPI、システム・プロパティおよびjaxp.propertiesファイルによってサポートされます。たとえば、USE_CATALOGがtrueに設定されており、特定のプロセッサに対するカタログ・サポートを無効化する場合は、プロセッサのsetFeatureメソッドを使用してUSE_CATALOG機能をfalseに設定します。次のコードでは、XMLReaderオブジェクトに対して、USE_CATALOG機能が指定値のuseCatalogに設定されます。

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setNamespaceAware(true);
XMLReader reader = spf.newSAXParser().getXMLReader();
if (setUseCatalog) {
reader.setFeature(XMLConstants.USE_CATALOG, useCatalog);
}

一方、環境全体でカタログをオフにする必要がある場合は、jaxp.propertiesファイルに次の行を構成します。

javax.xml.useCatalog = false;

javax.xml.catalog.files

javax.xml.catalog.filesプロパティはXMLカタログAPIによって定義され、JDK XMLプロセッサにその他のカタログ機能とともにサポートされます。システム・プロパティまたはjaxp.propertiesファイルを使用してプロセッサにFILESプロパティを設定するだけで、解析、検証または変換プロセスでカタログ機能を使用できます。

カタログURI

カタログ・ファイル参照は、file:///users/auser/catalog/catalog.xmlのような有効なURIである必要があります。

システムまたはカタログ・ファイルのURIエントリのURI参照は、絶対または相対で指定できます。相対の場合は、カタログ・ファイルのURIまたはベースURI(指定された場合)を使用して解決されます。

システム・エントリまたはuriエントリの使用

XMLカタログAPIを直接使用する場合(例は「XMLカタログAPI」を参照)、JDK XMLプロセッサでCatalogFeaturesクラスのネイティブ・サポートを使用すると、systemエントリとuriエントリの両方が機能します。通常は、最初にsystemエントリ、次にpublicエントリが検索され、一致が見つからない場合はプロセッサによって引き続きuriエントリが検索されます。systemエントリとuriエントリの両方がサポートされるため、systemまたはuriのどちらのエントリを使用するかを選択する場合は、XML仕様の慣例に従うことをお薦めします。たとえば、DTDはsystemIdを使用して定義されるため、systemエントリを使用することをお薦めします。

XMLプロセッサでのカタログの使用

XMLカタログAPIを様々なJava XMLプロセッサで使用します。

XMLカタログAPIはすべてのJDK XMLプロセッサでサポートされます。次の項では、特定のタイプのプロセッサでこれを有効化する方法について説明します。

DOMでのカタログの使用

DOMでカタログを使用するには、次のコードで示すように、DocumentBuilderFactoryインスタンスにFILESプロパティを設定します。

static final String CATALOG_FILE = CatalogFeatures.Feature.FILES.getPropertyName();
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
if (catalog != null) {
dbf.setAttribute(CATALOG_FILE, catalog);
}

catalogはカタログ・ファイルへのURIであることに注意してください。たとえば、"file:///users/auser/catalog/catalog.xml"のようになります。

解決対象のファイルとともにカタログ・エントリ・ファイルをデプロイするのが最良の方法であり、こうすることでファイルはカタログ・ファイルに対して相対的に解決されます。たとえば、カタログ・ファイルのuriエントリが次に示すようになっている場合、XSLImport_html.xslファイルは/users/auser/catalog/XSLImport_html.xslにあります。

<uri name="pathto/XSLImport_html.xsl" uri="XSLImport_html.xsl"/>

SAXでのカタログの使用

SAXパーサーでカタログ機能を使用するには、カタログ・ファイルをSAXParserインスタンスに設定します。

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setNamespaceAware(true);
spf.setXIncludeAware(true);
SAXParser parser = spf.newSAXParser();
parser.setProperty(CATALOG_FILE, catalog);

前述のサンプル・コードの文spf.setXIncludeAware(true)に注意してください。これが有効になっていると、XIncludeも同様にカタログを使用して解決されます。

XMLファイルXI_simple.xmlが次のようであるとします。

<simple>
<test xmlns:xinclude="http://www.w3.org/2001/XInclude">
<latin1>
<firstElement/>
<xinclude:include href="pathto/XI_text.xml" parse="text"/>
<insideChildren/>
<another>
<deeper>text</deeper>
</another>
</latin1>
<test2>
<xinclude:include href="pathto/XI_test2.xml"/>
</test2>
</test>
</simple>

さらに、別のXMLファイルXI_test2.xmlが次のようであるとします。

<?xml version="1.0"?>
<!-- comment before root -->
<!DOCTYPE red SYSTEM "pathto/XI_red.dtd">
<red xmlns:xinclude="http://www.w3.org/2001/XInclude">
<blue>
<xinclude:include href="pathto/XI_text.xml" parse="text"/>
</blue>
</red>

別のテキスト・ファイルXI_text.xmlに単純な文字列が含まれており、ファイルXI_red.dtdが次のようであるとします。

<!ENTITY red "it is read">

これらのXMLファイルにはXInclude要素の中にXInclude要素が含まれており、DTDへの参照があります。これらがカタログ・ファイルCatalogSupport.xmlとともに同じフォルダ内にある場合は、これらをマップするために次のカタログ・エントリを追加します。

<uri name="pathto/XI_text.xml" uri="XI_text.xml"/>
<uri name="pathto/XI_test2.xml" uri="XI_test2.xml"/>
<system systemId="pathto/XI_red.dtd" uri="XI_red.dtd"/>

XI_simple.xmlファイルを解析するためにparser.parseメソッドがコールされると、指定されたカタログを使用して、XI_simple.xmlファイルの中のXI_test2.xmlを見つけることができ、XI_test2.xmlファイルの中のXI_text.xmlファイルとXI_red.dtdファイルを見つけることができます。

StAXでのカタログの使用

StAXパーサーでカタログ機能を使用するには、XMLStreamReaderオブジェクトを作成する前に、カタログ・ファイルをXMLInputFactoryインスタンスに設定します。

XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(CatalogFeatures.Feature.FILES.getPropertyName(), catalog);
XMLStreamReader streamReader = factory.createXMLStreamReader(xml, new FileInputStream(xml));

XMLソースの解析にXMLStreamReader streamReaderオブジェクトを使用すると、ソースの外部参照はカタログに指定されているエントリに従って解決されます。

setFeatureメソッドとsetAttributeメソッドの両方を持っているDocumentBuilderFactoryクラスとは異なり、XMLInputFactoryではsetPropertyメソッドのみが定義されることに注意してください。XMLConstants.USE_CATALOGを含むXMLカタログAPIはすべて、このsetPropertyメソッドを使用して設定されます。たとえば、XMLStreamReaderオブジェクトでUSE_CATALOGを無効化するには、次のようにします。

factory.setProperty(XMLConstants.USE_CATALOG, false);

スキーマ検証でのカタログの使用

カタログを使用してスキーマ内の外部リソースを解決するには(XSD importおよびincludeなど)、SchemaFactoryオブジェクトにカタログを設定します。

SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
factory.setProperty(CatalogFeatures.Feature.FILES.getPropertyName(), catalog);
Schema schema = factory.newSchema(schemaFile);

XMLSchemaスキーマ・ドキュメントには外部DTDへの参照が含まれています。

<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "pathto/XMLSchema.dtd" [
...
]>

およびxsdインポートも含まれています。

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/pathto/xml.xsd">
<xs:annotation>
<xs:documentation>Get access to the xml: attribute groups for xml:lang
as declared on 'schema' and 'documentation' below
</xs:documentation>
</xs:annotation>
</xs:import>

この例に従ってローカル・リソースを使用すると、W3Cサーバーへのコールが減ることによってアプリケーションのパフォーマンスが改善します。

- SchemaFactoryオブジェクトに設定されているカタログに次のエントリを含めます。

<public publicId="-//W3C//DTD XMLSCHEMA 200102//EN" uri="XMLSchema.dtd"/>
<!-- XMLSchema.dtd refers to datatypes.dtd -->
<systemSuffix systemIdSuffix="datatypes.dtd" uri="datatypes.dtd"/>
<uri name="http://www.w3.org/2001/pathto/xml.xsd" uri="xml.xsd"/>

- XMLSchema.dtd、datatypes.dtdおよびxml.xsdのソース・ファイルをダウンロードし、カタログ・ファイルとともに保存します。

前述のとおり、XMLカタログAPIでは任意のエントリ・タイプを使用できます。前述のケースでは、uriエントリのかわりに次のいずれかを使用できます。

- publicエントリ。import要素のnamespace属性がpublicId要素として扱われるためです。

<public publicId="http://www.w3.org/XML/1998/namespace" uri="xml.xsd"/>

- systemエントリ。

<system systemId="http://www.w3.org/2001/pathto/xml.xsd" uri="xml.xsd"/>

注意:
XMLカタログAPIを使用したテストでは、サンプル・ファイルで使用されるURIまたはシステムIDが、インターネット上にある実際のリソース(特にW3Cサーバー)をポイントしていないことを確認してください。これによって、カタログの解決の失敗を早期に発見でき、W3Cサーバーに負荷をかけることなく、不要な接続を防ぐことができます。そのため、このトピックおよびXMLカタログAPIに関係するその他のトピックでは、すべての例のURIに恣意的な文字列"pathto"が追加されており、URIが外部のW3Cリソースに解決されないようにしています。

カタログを使用して検証対象のXMLソースの外部リソースを解決するには、Validatorオブジェクトにカタログを設定します。

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema();
Validator validator = schema.newValidator();
validator.setProperty(CatalogFeatures.Feature.FILES.getPropertyName(), catalog);
StreamSource source = new StreamSource(new File(xml));
validator.validate(source);

変換でのカタログの使用

XSLT変換プロセスでXMLカタログAPIを使用するには、TransformerFactoryオブジェクトにカタログ・ファイルを設定します。

TransformerFactory factory = TransformerFactory.newInstance();
factory.setAttribute(CatalogFeatures.Feature.FILES.getPropertyName(), catalog);
Transformer transformer = factory.newTransformer(xslSource);

Transformerオブジェクトを作成するためにファクトリで使用しているXSLソースに次のようなDTD、import文およびinclude文が含まれている場合、

<!DOCTYPE HTMLlat1 SYSTEM "http://openjdk.java.net/xml/catalog/dtd/XSLDTD.dtd">
<xsl:import href="pathto/XSLImport_html.xsl"/>
<xsl:include href="pathto/XSLInclude_header.xsl"/>

これらの参照を解決するために次のカタログ・エントリを使用できます。

<system systemId="http://openjdk.java.net/xml/catalog/dtd/XSLDTD.dtd" uri="XSLDTD.dtd"/>
<uri name="pathto/XSLImport_html.xsl" uri="XSLImport_html.xsl"/>
<uri name="pathto/XSLInclude_header.xsl" uri="XSLInclude_header.xsl"/>

リゾルバのコール順序

JDK XMLプロセッサはカタログ・リゾルバの前にカスタム・リゾルバをコールします。

カタログ・リゾルバより優先されるカスタム・リゾルバ

カタログ・ファイルが設定されているJDK XMLプロセッサでは、カタログ・リゾルバ(CatalogResolverインタフェースで定義される)を使用して外部参照を解決できます。ただし、カスタム・リゾルバも指定されている場合は、これが常にカタログ・リゾルバより優先されます。つまり、JDK XMLは最初にカスタム・リゾルバをコールして外部リソースの解決を試行します。正常に解決された場合、プロセッサはカタログ・リゾルバをスキップして続行します。カスタム・リゾルバがないか、カスタム・リゾルバによる解決でnullが返された場合にのみ、プロセッサはカタログ・リゾルバをコールします。

カスタム・リゾルバを使用するアプリケーションでは、カスタム・リゾルバが処理できないリソースを解決するために、追加のカタログを設定します。コードを変更できない既存のアプリケーションでは、システム・プロパティを使用してカタログを設定するか、jaxp.propertiesファイルで外部参照を(この設定によってカスタム・リゾルバが処理する既存のプロセスに干渉しないことがわかっている)ローカル・リソースにリダイレクトします。

エラーの検出

問題を分離して構成の問題を検出します。

XMLカタログ標準では、プロセッサがリソースの障害からリカバリできることを必要としています。そのため、XMLカタログAPIでは、問題のあるカタログ・エントリ・ファイルはエラーが発行されることなく無視されます。これによって構成の問題を検出するのが難しくなります。

構成の問題の検出

構成の問題を検出するには、カタログを1つずつ設定し、RESOLVEの値をstrictに設定し、一致が見つからなかった場合はCatalogException例外を確認することで、問題を分離します。

表2-1 RESOLVEの設定

RESOLVEの値

CatalogResolverの動作

説明

strict(デフォルト)

指定された参照に一致が見つからなかった場合はCatalogExceptionがスローされます

参照の不一致は、カタログの内容またはカタログの設定にエラーがあることを示します。

continue

動作なし

これは、カタログに含まれていない外部参照を解決するためにXMLプロセッサを続行する、本番環境での使用に適しています。

ignore

動作なし

外部参照のスキップが許可されるSAXのようなプロセッサの場合、ignore値はCatalogResolverオブジェクトに、空のInputSourceオブジェクトを返すことを指示します。これによって外部参照はスキップされます。

3 不変のリスト、セットおよびマップの作成

JDK 9でリスト、セットおよびマップの各インタフェースに追加されたコンビニエンス静的ファクトリ・メソッドによって、不変のリスト、セットおよびマップを簡単に作成できるようになりました。

構築後に状態を変更できないオブジェクトは、不変オブジェクトとみなされます。コレクションの不変インスタンスが作成されると、これに対する参照が存在するかぎり、ここには同じデータが保持され続けます。

これらのメソッドを使用して作成されたコレクションに不変オブジェクトが含まれている場合、これらは構築後自動的にスレッド・セーフになります。構造で変更をサポートする必要がないため、少ない領域で効率的に作成できます。通常、不変コレクションのインスタンスのメモリー消費量は、可変の場合よりはるかに少なくなります。

「不変性について」で説明しているとおり、不変コレクションには可変オブジェクトを含めることができます。含まれている場合、そのコレクションは不変でもスレッド・セーフでもなくなります。

トピック

- ユースケース

- 構文

- ランダム化された反復順序

- 不変性について

- 領域効率

ユースケース

不変メソッドの一般的なユースケースは、既知の値で初期化され、まったく変更されないコレクションです。また、データの変更頻度が低い場合も、これらのメソッドの使用を検討してください。

パフォーマンスを最適化するには、不変コレクションに変更されないデータ・セットを保存します。ただし、変更されるデータについても、パフォーマンスと領域効率が改善されます。時々変更されるデータの場合も、これらのコレクションを使用すると、可変コレクションよりパフォーマンスが改善されます。

値の数が多い場合は、HashMapに保存することを検討してください。エントリの追加と削除が常に発生する場合に適しています。ただし、値のセットがまったく変更されない、またはめったに変更されない場合に、そのセットを頻繁に読み取るのであれば、不変マップが最も適しています。データ・セットの読取りが頻繁に行われ、その値がめったに変更されない場合は、値が変更されたときに不変マップを破棄して再構築することによるパフォーマンスの影響を考慮しても、全体的な時間効率が向上します。

構文

これらの新しいコレクションのAPIは、要素の数が少ない場合は特にシンプルです。

トピック

- 不変リストの静的ファクトリ・メソッド

- 不変セットの静的ファクトリ・メソッド

- 不変マップの静的ファクトリ・メソッド

不変リストの静的ファクトリ・メソッド

List.of静的ファクトリ・メソッドを使用すると、不変リストを簡単に作成できます。

リストは順序付けされたコレクションであり、通常は重複要素が許可されます。NULL値は設定できません。

これらのメソッドの構文は次のとおりです。

List.of()
List.of(e1)
List.of(e1, e2)         // fixed-argument form overloads up to 10 elements
List.of(elements...)   // varargs form supports an arbitrary number of elements or an array

例3-1 例

JDK 8の場合:

List<String> stringList = Arrays.asList("a", "b", "c");
stringList = Collections.unmodifiableList(stringList);

JDK 9の場合:

List stringList = List.of("a", "b", "c");

「不変リストの静的ファクトリ・メソッド」を参照してください。

不変セットの静的ファクトリ・メソッド

Set.of静的ファクトリ・メソッドを使用すると、不変セットを簡単に作成できます。

セットは、重複要素を含まないコレクションです。重複エントリが検出された場合は、IllegalArgumentExceptionがスローされます。NULL値は設定できません。

これらのメソッドの構文は次のとおりです。

Set.of()
Set.of(e1)
Set.of(e1, e2)         // fixed-argument form overloads up to 10 elements
Set.of(elements...)   // varargs form supports an arbitrary number of elements or an array

例3-2 例

JDK 8の場合:

Set<String> stringSet = new HashSet<>(Arrays.asList("a", "b", "c"));
stringSet = Collections.unmodifiableSet(stringSet);

JDK 9の場合:

Set<String> stringSet = Set.of("a", "b", "c");

「不変セットの静的ファクトリ・メソッド」を参照してください。

不変マップの静的ファクトリ・メソッド

Map.ofとMap.ofEntriesの各静的ファクトリ・メソッドを使用すると、不変マップを簡単に作成できます。

マップには、同一のキーを複数登録できません。各キーは1つの値にしかマッピングできません。重複キーが検出された場合は、IllegalArgumentExceptionがスローされます。Null値はマップのキーまたは値として使用できません。

これらのメソッドの構文は次のとおりです。

Map.of()
Map.of(k1, v1)
Map.of(k1, v1, k2, v2)    // fixed-argument form overloads up to 10 key-value pairs
Map.ofEntries(entry(k1, v1), entry(k2, v2),...)
// varargs form supports an arbitrary number of Entry objects or an array

例3-3 例

JDK 8の場合:

Map<String, Integer> stringMap = new HashMap<String, Integer>();
stringMap.put("a", 1);
stringMap.put("b", 2);
stringMap.put("c", 3);
stringMap = Collections.unmodifiableMap(stringMap);

JDK 9の場合:

Map stringMap = Map.of("a", 1, "b", 2, "c", 3);

例3-4 任意の数のペアを持つマップ

キーと値のペアの数が10を超える場合は、Map.entryメソッドを使用してマップのエントリを作成し、それらのオブジェクトをMap.ofEntriesメソッドに渡します。次に例を示します。

import static java.util.Map.entry;
Map <Integer, String> friendMap = Map.ofEntries(
entry(1, "Tom"),
entry(2, "Dick"),
entry(3, "Harry"),
...
entry(99, "Mathilde"));

「不変マップの静的ファクトリ・メソッド」を参照してください。

ランダム化された反復順序

Set要素およびMapキーの反復順序がランダム化されました。これはJVMの実行ごとに異なる可能性があります。これは意図的な動作です - これによって、反復順序に依存するコードの識別が容易になります。コードに潜む反復順序の依存性によって、デバッグするのが難しい問題が発生することがあります。

jshellが再起動するまで反復順序が同じであることがわかります。

jshell> Map stringMap = Map.of("a", 1, "b", 2, "c", 3);
stringMap ==> {b=2, c=3, a=1}

jshell> Map stringMap = Map.of("a", 1, "b", 2, "c", 3);
stringMap ==> {b=2, c=3, a=1}

jshell> /exit
|  Goodbye

C:\Program Files\Java\jdk-9\bin>jshell
|  Welcome to JShell -- Version 9-ea
|  For an introduction type: /help intro

jshell> Map stringMap = Map.of("a", 1, "b", 2, "c", 3);
stringMap ==> {a=1, b=2, c=3}

Set.of、Map.ofおよびMap.ofEntriesの各メソッドを使用して作成されたコレクション・インスタンスの反復順序のみがランダム化されています。HashMapおよびHashSetなどのコレクション実装の反復順序に変更はありません。

不変性について

JDK 9で追加されたコンビニエンス・ファクトリ・メソッドによって返されるコレクションは、慣例的に不変です。これらのコレクションに対して要素の追加、設定または削除を試行すると、UnsupportedOperationExceptionがスローされます。

これらのコレクションは「不変持続」コレクションまたは「機能」コレクションではありません。これらのいずれかのコレクションを使用している場合、これを変更することはできますが、変更した場合は、最初のコレクションと同じ構造の新しく更新されたコレクションが返されます。

不変コレクションの利点の1つは、自動的にスレッド・セーフであることです。コレクションを作成したら、複数のスレッドに渡すことができ、そこでは一貫したビューが表示されます。

ただし、オブジェクトの不変コレクションは不変オブジェクトのコレクションと同じではありません。含まれている要素が可変要素である場合は、コレクションの動作の一貫性が失われるか、コレクションのコンテンツが変更されます。

不変コレクションに可変要素が含まれている場合の例を示します。jshellを使用して、ArrayListクラスを使用した文字列オブジェクトのリストを2つ作成します。ここで、2番目のリストは1番目のリストをコピーして作成します。トリビアルjshell出力は削除されました。

jshell> List<String> list1 = new ArrayList<>();
jshell> list1.add("a")
jshell> list1.add("b")
jshell> list1
list1 ==> [a, b]

jshell> List<String> list2 = new ArrayList<>(list1);
list2 ==> [a, b]

次に、List.ofメソッドを使用して、最初に作成したリストをポイントするilist1とilist2を作成します。ilist1の変更を試行すると、ilist1は不変であるため、例外エラーが表示されます。変更を試行すると例外がスローされます。

jshell> List<List<String>> ilist1 = List.of(list1, list1);
ilist1 ==> [[a, b], [a, b]]

jshell> List<List<String>> ilist2 = List.of(list2, list2);
ilist2 ==> [[a, b], [a, b]]

jshell> ilist1.add(new ArrayList<String>())
|  java.lang.UnsupportedOperationException thrown:
|        at ImmutableCollections.uoe (ImmutableCollections.java:70)
|        at ImmutableCollections$AbstractImmutableList.add (ImmutableCollections
.java:76)
|        at (#10:1)

ただし、元のlist1を変更した場合、ilist1とilist2は等しくなくなります。

jshell> list1.add("c")
jshell> list1
list1 ==> [a, b, c]
jshell> ilist1
ilist1 ==> [[a, b, c], [a, b, c]]

jshell> ilist2
ilist2 ==> [[a, b], [a, b]]

jshell> ilist1.equals(ilist2)
$14 ==> false

不変と同じではない変更不可能

不変コレクションはCollections.unmodifiable...ラッパーと同じように動作します。ただし、これらのコレクションはラッパーではありません - これらはクラスによって実装されたデータ構造であり、データの変更を試行すると例外がスローされます。

リストを作成してCollections.unmodifiableListメソッドに渡した場合は、変更不可能なビューを取得します。基となるリストは変更可能であり、これを変更した場合は返されるリストに表示されるため、実際には不変ではありません。

この動作を確認するには、リストを作成してCollections.unmodifiableListに渡します。そのリストに直接追加しようとすると、例外がスローされます。

jshell> List<String> unmodlist1 = Collections.unmodifiableList(list1);
unmodlist1 ==> [a, b, c]

jshell> unmodlist1.add("d")
|  java.lang.UnsupportedOperationException thrown:
|        at Collections$UnmodifiableCollection.add (Collections.java:1056)
|        at (#17:1)

ただし、元のlist1を変更した場合、エラーは生成されず、unmodlist1リストが変更されます。

jshell> list1.add("d")
$19 ==> true
jshell> list1
list1 ==> [a, b, c, d]

jshell> unmodlist1
unmodlist1 ==> [a, b, c, d]

領域効率

コンビニエンス・ファクトリ・メソッドによって返されるコレクションは、同等の可変コレクションより領域効率に優れています。

これらのコレクションのすべての実装は、静的ファクトリ・メソッドの背後にあるプライベート・クラスです。これがコールされると、静的ファクトリ・メソッドはサイズに基づいて実装クラスを選択します。データは圧縮されたフィールドベースまたは配列ベースのレイアウトに保存されます。

2つの代替実装によって消費されるヒープ領域を示します。まず、2つの文字列が含まれる変更不可能なHashSetを示します。

Set<String> set = new HashSet<>(3);   // 3 buckets
set.add("silly");
set.add("string");
set = Collections.unmodifiableSet(set);
セットには、変更不可能なラッパー、HashSet、それに含まれるHashMap、バケットの表(配列)、2つのノード・インスタンス(要素ごとに1つ)、の6つのオブジェクトが含まれています。オブジェクトごとに12バイトのヘッダーを持つ通常のVMでは、セットのオーバーヘッド合計は96バイト + 28 * 2 = 152バイトになります。これは、保存されるデータ量に対して大きなオーバーヘッド容量です。さらに、データにアクセスするために複数のメソッドのコールや異なるポインタが必要になります。

かわりに、Set.ofを使用してセットを実装します。

Set<String> set = Set.of("silly", "string");

これはフィールドベースの実装であるため、セットには1つのオブジェクトと2つのフィールドが含まれます。オーバーヘッドは20バイトです。新しいコレクションが消費するヒープ領域は、要素ごとの固定オーバーヘッドであるため、小さくなります。

変更をサポートしないこともまた、領域の節約に貢献します。さらに、データを保持する必要があるオブジェクトが少なくなるため、ローカル参照が改善されます。

4 プロセスAPI

プロセスAPIを使用すると、ネイティブ・オペレーティング・システムのプロセスを起動し、これに関する情報を取得し、管理することができます。

このAPIを使用して、オペレーティング・システムのプロセスを操作できます。次に例を示します。

- 任意のコマンドを実行します。

- 実行中のプロセスをフィルタします。

- 出力をリダイレクトします。

- 1つのプロセスが終了したら別のプロセスが起動するようにスケジュールすることによって、種類が異なるコマンドやシェルを連結します。

- コマンドの実行をテストします。

- 一連のテストを実行します。

- ログを出力します。

- 残ったプロセスをクリーン・アップします。

- コマンドをモニターします。

- 実行時間が長いプロセスをモニターし、終了した場合に再起動します

- 使用状況の統計を収集します

トピック

- プロセスAPIのクラスとインタフェース

- プロセスの作成

- プロセスに関する情報の取得

- プロセスからの出力のリダイレクト

- ストリームでのプロセスのフィルタリング

- プロセス終了時のonExitメソッドを使用したプロセスの処理

- 機密プロセス情報へのアクセスの制御

プロセスAPIのクラスとインタフェース

プロセスAPIは、ProcessBuilder、Process、ProcessHandle、ProcessHandle.Infoのクラスおよびインタフェースで構成されます。

トピック

- ProcessBuilderクラス

- Processクラス

- ProcessHandleインタフェース

- ProcessHandle.Infoインタフェース

ProcessBuilderクラス

ProcessBuilderクラスを使用して、オペレーティング・システムのプロセスを作成および起動します。

プロセスの作成および起動方法の例は、「プロセスの作成」を参照してください。ProcessBuilderクラスでは様々なプロセス属性を管理します。次の表にサマリーを示します。

表4-1 ProcessBuilderクラスの属性と関連メソッド

プロセス属性

説明

関連メソッド

コマンド

コールする外部プログラム・ファイルとその引数(ある場合)を指定する文字列。

- ProcessBuilderコンストラクタ

- command(String... command)

環境

環境変数(およびその値)。この初期値は現在のプロセスのシステム環境のコピーです。

- environment()

作業ディレクトリ

デフォルトでは、現在のプロセスの現在の作業ディレクトリです。

- directory()

- directory(File directory)

標準入力ソース

デフォルトでは、プロセスは標準入力をパイプから読み取ります。Process.getOutputStreamメソッドによって返される出力ストリームを使用してこれにアクセスします。

- redirectInput(ProcessBuilder.Redirect source)

標準出力と標準エラーの出力先

デフォルトでは、プロセスは標準出力と標準エラーをパイプに書き込みます。Process.getInputStreamメソッドとProcess.getErrorStreamメソッドによって返される入力ストリームを使用してこれらにアクセスします。「プロセスからの出力のリダイレクト」の例を参照してください。

- redirectOutput(ProcessBuilder.Redirect destination)

- redirectError(ProcessBuilder.Redirect destination)

redirectErrorStreamプロパティ

標準出力とエラー出力を2つの個別のストリームとして送信する(値をfalseにする)か、エラー出力を標準出力とマージする(値をtrueにする)かを指定します。

- redirectErrorStream()

- redirectErrorStream(boolean redirectErrorStream)

Processクラス

Processクラスのメソッドを使用して、ProcessBuilder.startメソッドとRuntime.execメソッドによって起動されたプロセスを制御します。次の表に、これらのメソッドのサマリーを示します。

次の表では、Processクラスのメソッドのサマリーを示します。

表4-2 Processクラスのメソッド

メソッド・タイプ

関連メソッド

プロセスが完了するまで待機します。

- waitfor()

- waitFor(long timeout, TimeUnit unit)

プロセスに関する情報を取得します。

- isAlive()

- pid()

- info()

- exitValue()

入力、出力およびエラーの各ストリームを取得します。「プロセス終了時のonExitメソッドを使用したプロセスの処理」の例を参照してください。

- getInputStream()

- getOutputStream()

- getErrorStream()

直接子プロセスと間接子プロセスを取得します。

- children()

- descendants()

プロセスを破棄または終了します。

- destroy()

- destroyForcibly()

- supportsNormalTermination()

プロセスが終了するときに完了する予定のCompletableFutureインスタンスを返します。「プロセス終了時のonExitメソッドを使用したプロセスの処理」の例を参照してください。

- onExit()

ProcessHandleインタフェース

ProcessHandleインタフェースを使用してネイティブ・プロセスを識別および制御します。ProcessクラスはProcessHandleと異なり、ProcessBuilder.startメソッドとRuntime.execメソッドによって起動されたプロセスのみを制御します。ただし、Processクラスを使用してプロセス入力、出力およびエラー・ストリームにアクセスすることはできます。

「ストリームでのプロセスのフィルタリング」のProcessHandleインタフェースの例を参照してください。次の表では、このインタフェースのサマリーを示します。

表4-3 ProcessHandleインタフェースのメソッド

メソッド・タイプ

関連メソッド

すべてのオペレーティング・システム・プロセスを取得します。

- allProcesses()

プロセス・ハンドルを取得します。

- current()

- of(long pid)

- parent()

プロセスに関する情報を取得します。

- isAlive()

- pid()

- info()

直接子プロセスと間接子プロセスのストリームを取得します。

- children()

- descendants()

プロセスを破棄します。

- destroy()

- destroyForcibly()

プロセスが終了するときに完了する予定のCompletableFutureインスタンスを返します。「プロセス終了時のonExitメソッドを使用したプロセスの処理」の例を参照してください。

- onExit()

ProcessHandle.Infoインタフェース

ProcessHandle.Infoインタフェースを使用して、プロセス(ProcessBuilder.startメソッドとネイティブ・プロセスによって作成されたプロセスを含む)に関する情報を取得します。

「プロセスに関する情報の取得」のProcessHandle.Infoインタフェースの例を参照してください。次の表では、このインタフェースのサマリーを示します。

表4-4 ProcessHandle.Infoインタフェースのメソッド

メソッド

説明

arguments()

プロセスの引数をString配列として返します。

command()

プロセスの実行可能ファイルのパス名を返します。

commandLine()

プロセスのコマンドラインを返します。

startInstant()

プロセスの開始時間を返します。

totalCpuDuration()

プロセスの累積CPU時間合計を返します。

user()

プロセスのユーザーを返します。

プロセスの作成

プロセスを作成するには、まずProcessBuilderクラスにコマンド名とその引数などのプロセスの属性を指定します。次に、ProcessBuilder.startメソッドを使用してプロセスを起動します。これによってProcessインスタンスが返されます。

次の行によってプロセスが作成および起動されます。

ProcessBuilder pb = new ProcessBuilder("echo", "Hello World!");
Process p = pb.start();

次の引用では、setEnvTestメソッドによってhorseとoatsの2つの環境変数が設定され、次にechoコマンドによってこれらの環境変数(およびシステム環境変数HOME)の値が出力されます。

public static void setEnvTest() throws IOException, InterruptedException {
ProcessBuilder pb =
new ProcessBuilder("/bin/sh", "-c", "echo $horse $dog $HOME").inheritIO();
pb.environment().put("horse", "oats");
pb.environment().put("dog", "treats");
pb.start().waitFor();
}

このメソッドの出力を次に示します(ホーム・ディレクトリは/home/adminであるとします)。

oats treats /home/admin

プロセスに関する情報の取得

Process.pidメソッドによってプロセスのネイティブ・プロセスIDが返されます。Process.infoメソッドによって、プロセスに関する追加の情報(実行可能ファイルのパス名、開始時間、ユーザーなど)が含まれるProcessHandle.Infoインスタンスが返されます。

次の引用では、getInfoTestメソッドによってプロセスが起動され、次にプロセスに関する情報が出力されます。

public static void getInfoTest() throws IOException {
ProcessBuilder pb = new ProcessBuilder("echo", "Hello World!");
String na = "<not available>";
Process p = pb.start();
ProcessHandle.Info info = p.info();
System.out.printf("Process ID: %s%n", p.pid());
System.out.printf("Command name: %s%n", info.command().orElse(na));
System.out.printf("Command line: %s%n", info.commandLine().orElse(na));

System.out.printf("Start time: %s%n",
info.startInstant().map(i -> i.atZone(ZoneId.systemDefault())
.toLocalDateTime().toString())
.orElse(na));

System.out.printf("Arguments: %s%n",
info.arguments().map(a -> Stream.of(a)
.collect(Collectors.joining(" ")))
.orElse(na));

System.out.printf("User: %s%n", info.user().orElse(na));
}

このメソッドによって、次のような出力が表示されます。

Process ID: 18761
Command name: /usr/bin/echo
Command line: echo Hello World!
Start time: 2017-05-30T18:52:15.577
Arguments: <not available>
User: administrator

注意:

- プロセスの属性はオペレーティング・システムによって異なり、すべての実装で使用できるわけではありません。また、プロセスに関する情報は、リクエストを作成したプロセスのオペレーティング・システム権限によって制限されます。

- ProcessHandle.Infoインタフェースのすべてのメソッドでは、Optional<T>のインスタンスが返されます。戻り値が空かどうか常に確認してください。

プロセスからの出力のリダイレクト

デフォルトでは、プロセスは標準出力と標準エラーをパイプに書き込みます。アプリケーションでは、Process.getOutputStreamメソッドおよびProcess.getErrorStreamメソッドから返される入力ストリームを使用して、これらのパイプにアクセスできます。ただし、プロセスの起動前に、redirectOutputメソッドとredirectErrorメソッドを使用して、標準出力と標準エラーをファイルなどの他の出力先にリダイレクトすることができます。

次の引用では、redirectToFileTestメソッドによって標準入力がファイルout.tmpにリダイレクトされ、次にこのファイルが出力されます。

public static void redirectToFileTest() throws IOException, InterruptedException {
File outFile = new File("out.tmp");
Process p = new ProcessBuilder("ls", "-la")
.redirectOutput(outFile)
.redirectError(Redirect.INHERIT)
.start();
int status = p.waitFor();
if (status == 0) {
p = new ProcessBuilder("cat" , outFile.toString())
.inheritIO()
.start();
p.waitFor();
}
}

引用では、標準出力はファイルout.tmpにリダイレクトされます。標準エラーは起動したプロセスの標準エラーにリダイレクトされます。値Redirect.INHERITによって、サブプロセスI/Oのソースまたは出力先は現在のプロセスと同じに指定されます。inheritIO()メソッドへのコールはredirectInput(Redirect.INHERIT).redirectOuput(Redirect.INHERIT).redirectError(Redirect.INHERIT)と同等です。

ストリームでのプロセスのフィルタリング

ProcessHandle.allProcessesメソッドでは、現在のプロセスで参照可能なすべてのプロセスのストリームが返されます。コレクションから要素をフィルタするのと同じ方法を使用して、このストリームのProcessHandleインスタンスをフィルタできます。

次の引用では、filterProcessesTestメソッドによって、現在のユーザーが所有しているすべてのプロセスに関する情報が、親プロセスのプロセスIDでソートされて出力されます。

public class ProcessTest {

// ...

static void filterProcessesTest() {
Optional<String> currUser = ProcessHandle.current().info().user();
ProcessHandle.allProcesses()
.filter(p1 -> p1.info().user().equals(currUser))
.sorted(ProcessTest::parentComparator)
.forEach(ProcessTest::showProcess);
}

static int parentComparator(ProcessHandle p1, ProcessHandle p2) {
long pid1 = p1.parent().map(ph -> ph.pid()).orElse(-1L);
long pid2 = p2.parent().map(ph -> ph.pid()).orElse(-1L);
return Long.compare(pid1, pid2);
}

static void showProcess(ProcessHandle ph) {
ProcessHandle.Info info = ph.info();
System.out.printf("pid: %d, user: %s, cmd: %s%n",
ph.pid(), info.user().orElse("none"), info.command().orElse("none"));
}

// ...
}

allProcessesメソッドはネイティブ・オペレーティング・システムのアクセス制御によって制限されることに注意してください。また、すべてのプロセスは非同期に作成され終了するため、ストリーム内のプロセスがアライブであること、またはallProcessesメソッドをコールした後に他のプロセスが作成されていないことは保証されません。

プロセス終了時のonExitメソッドを使用したプロセスの処理

Process.onExitメソッドとProcessHandle.onExitメソッドによってCompletableFutureインスタンスが返されます。これを使用してプロセス終了時のタスクをスケジュールできます。または、アプリケーションでプロセスが終了するまで待機する場合は、onExit().get()をコールします。

次の引用では、startProcessesTestメソッドによって3つのプロセスが作成され、起動されます。その後、各プロセスでonExit().thenAccept(onExitMethod)がコールされます。onExitMethodによってプロセスID (PID)、終了ステータスおよびプロセスの出力が表示されます。

public class ProcessTest {

// ...

static public void startProcessesTest() throws IOException, InterruptedException {
List<ProcessBuilder> greps = new ArrayList<>();
greps.add(new ProcessBuilder("/bin/sh", "-c", "grep -c \"java\" *"));
greps.add(new ProcessBuilder("/bin/sh", "-c", "grep -c \"Process\" *"));
greps.add(new ProcessBuilder("/bin/sh", "-c", "grep -c \"onExit\" *"));
ProcessTest.startSeveralProcesses (greps, ProcessTest::printGrepResults);
System.out.println("\nPress enter to continue ...\n");
System.in.read();
}

static void startSeveralProcesses (
List<ProcessBuilder> pBList,
Consumer<Process> onExitMethod)
throws InterruptedException {
System.out.println("Number of processes: " + pBList.size());
pBList.stream().forEach(
pb -> {
try {
Process p = pb.start();
System.out.printf("Start %d, %s%n",
p.pid(), p.info().commandLine().orElse("<na>"));
p.onExit().thenAccept(onExitMethod);
} catch (IOException e) {
System.err.println("Exception caught");
e.printStackTrace();
}
}
);
}

static void printGrepResults(Process p) {
System.out.printf("Exit %d, status %d%n%s%n%n",
p.pid(), p.exitValue(), output(p.getInputStream()));
}

private static String output(InputStream inputStream) {
String s = "";
try (BufferedReader br = new BufferedReader(new InputStreamReader(inputStream))) {
s = br.lines().collect(Collectors.joining(System.getProperty("line.separator")));
} catch (IOException e) {
System.err.println("Caught IOException");
e.printStackTrace();
}
return s;
}

// ...
}

startProcessesTestメソッドによって次のように出力されます。プロセスの終了順序が開始順序と異なる場合があることに注意してください。

Number of processes: 3
Start 12401, /bin/sh -c grep -c "java" *
Start 12403, /bin/sh -c grep -c "Process" *
Start 12404, /bin/sh -c grep -c "onExit" *

Press enter to continue ...

Exit 12401, status 0
ProcessTest.class:0
ProcessTest.java:16

Exit 12404, status 0
ProcessTest.class:0
ProcessTest.java:8

Exit 12403, status 0
ProcessTest.class:0
ProcessTest.java:38

このメソッドはSystem.in.read()メソッドをコールして、すべてのプロセスが終了(およびthenAcceptメソッドで指定されたメソッドを実行)する前にプログラムが終了することを防ぎます。

残りのプログラム処理に進む前にプロセスが終了するまで待機する場合は、onExit().get()をコールします。

static void startSeveralProcesses (
List<ProcessBuilder> pBList, Consumer<Process> onExitMethod)
throws InterruptedException {
System.out.println("Number of processes: " + pBList.size());
pBList.stream().forEach(
pb -> {
try {
Process p = pb.start();
System.out.printf("Start %d, %s%n",
p.pid(), p.info().commandLine().orElse("<na>"));
p.onExit().get();
printGrepResults(p);
} catch (IOException|InterruptedException|ExecutionException e ) {
System.err.println("Exception caught");
e.printStackTrace();
}
}
);
}

次に示すように、ComputableFutureクラスには様々なメソッドが用意されており、これをコールしてプロセス終了時のタスクをスケジュールできます。

- thenApply: 関数タイプのラムダ式(値を返すラムダ式)を使用する点以外はthenAcceptと同じです。

- thenRun: 実行可能タイプの(仮パラメータまたは戻り値がない)ラムダ式を使用します。

- thenApplyAsyc: ForkJoinPool.commonPool()からのスレッドで指定された関数を実行します。

ComputableFutureではFutureインタフェースが実装されるため、このクラスにも同期メソッドが含まれています。

- get(long timeout, TimeUnit unit): 必要に応じてプロセスが終了するまで(引数で指定された時間まで)待機します。

- isDone: プロセスが完了している場合はtrueを返します。

機密プロセス情報へのアクセスの制御

プロセス情報には、ユーザーID、パス、コマンドの引数などの機密情報が含まれている場合があります。セキュリティ・マネージャを使用してプロセス情報へのアクセスを制御します。

標準アプリケーションとして実行している場合、ProcessHandleは他のプロセスに関する情報に対してネイティブ・アプリケーションと同じオペレーティング・システム権限を持っています。ただし、システム・プロセスに関する情報を使用することはできません。

アプリケーションでSecurityManagerクラスを使用してセキュリティ・ポリシーを実装している場合、それを有効化してプロセス情報にアクセスするには、セキュリティ・ポリシーでRuntimePermission("manageProcess")を付与する必要があります。この権限によって、ネイティブ・プロセスの終了とプロセスのProcessHandle情報へのアクセスが有効になります。この権限によって、独自に作成していないプロセスの識別と終了をコードで行えるようになることに注意してください。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。