モジュール java.compiler

インタフェースProcessor

既知のすべての実装クラス:
AbstractProcessor

public interface Processor
注釈プロセッサのインタフェース。

注釈処理は、一連のラウンド内で実行されます。 各ラウンドでは、前回のラウンドで生成されたソース・ファイルとクラス・ファイルで見つかった注釈のサブセットの処理を、あるプロセッサが依頼される可能性があります。 1回目の処理ラウンドへの入力はツールの実行への初期入力になりますが、これらの初期入力は、仮想的な0回目の処理ラウンドの出力とみなすことができます。 あるプロセッサが特定のラウンドで処理を依頼された場合、たとえそのプロセッサの処理対象となる注釈が存在しない場合でも、そのプロセッサは最終ラウンドを含む後続のラウンドでも処理を依頼されます。 また、ツール・インフラストラクチャは、そのツールの操作によって暗黙的に生成されたファイルの処理を、プロセッサに依頼することもあります。

Processorの各実装では、ツールがプロセッサをインスタンス化するために使用するpublic引数なしコンストラクタを提供する必要があります。 ツール・インフラストラクチャとこのインタフェースを実装したクラスとの相互作用は、次のようになります。

  1. 既存のProcessorオブジェクトが使用されない場合、ツールは、あるプロセッサのインスタンスを作成するために、そのプロセッサのクラスの引数なしコンストラクタを呼び出す。
  2. 次に、ツールによって、適切なProcessingEnvironmentinitメソッドがコールされます。
  3. その後、ツールは、getSupportedAnnotationTypesgetSupportedOptions、およびgetSupportedSourceVersionを呼び出す。 これらのメソッドが呼び出されるのは、実行ごとに1回だけである。ラウンドごとに1回ではない。
  4. ツールは必要に応じて、Processorオブジェクトのprocessメソッドを呼び出す。ラウンドごとに新しいProcessorオブジェクトが作成されるわけではない
上記のプロトコルに従わずにプロセッサ・オブジェクトが作成および使用された場合、そのプロセッサの動作はこのインタフェース仕様では定義されません。

ツールは、検出処理を使って注釈プロセッサを見つけ出し、それらを実行すべきかどうかを決定します。 ツールを構成することで、可能性のあるプロセッサのセットを制御できます。 たとえば、JavaCompilerの場合、実行候補プロセッサのリストは、直接設定することも、サービススタイルの検索で使用される検索パスを使って制御することもできます。 ほかのツール実装は、コマンド行オプションなど、別の構成メカニズムを備えている可能性もありますが、その詳細については、特定のツールのドキュメントを参照してください。 ツールがrunに要求するプロセッサは、「ルート要素」上の注釈presentのインタフェースの機能、「プロセッサがサポートする注釈インタフェース」およびプロセッサ「処理する注釈インタフェースを要求」かどうかです。 プロセッサは、サポートする注釈インタフェースのサブセット(空のセットの場合もある)を処理するよう求められます。 ツールは、指定されたラウンドについて、ルート要素内に囲まれた要素に存在する注釈インタフェースのセットを計算します。 少なくとも1つの注釈インタフェースが存在する場合、プロセッサが注釈インタフェースを要求すると、それらは一致しない注釈インタフェースのセットから削除されます。 このセットが空になるか、使用可能なプロセッサがなくなると、そのラウンドは終了します。 注釈インタフェースが存在しない場合でも、注釈処理は行われますが、(empty)の注釈インタフェースのセットを要求できるのは、すべての注釈インタフェースの処理をサポートする「汎用プロセッサ」"*"のみです。

ラウンドのルート要素内に囲まれた要素に、そのインタフェースの注釈が少なくとも1つ存在する場合、注釈インタフェースは存在すると見なされます。 この目的のために、型パラメータはそのジェネリック要素で囲まれていると見なされます。 このため、パッケージ要素は、そのパッケージ内のトップレベルのクラスおよびインタフェースを囲むものとはみなされません。 (パッケージを表すルート要素は、package-infoファイルの処理時に作成されます。) 同様に、この目的のために、モジュール要素は、そのモジュール内のパッケージを囲むとはみなされません。 (モジュールを表すルート要素は、module-infoファイルの処理時に作成されます。) 「型の使用」の注釈は、要素の注釈とは対照的に、注釈インタフェースが存在するかどうかを計算するときに無視されます。

注釈は、AnnotatedConstructで特定される定義を満たす場合、presentです。 簡潔に言うと、検出の目的で注釈が存在すると見なされるのは、直接存在しているか継承を介して存在している場合です。 注釈がコンテナ注釈よってラップされている場合、存在しているとは見なされません 機能的には、要素に対してElements.getAllAnnotationMirrors(Element)を呼び出した結果に注釈が含まれる場合にかぎり、その注釈はその要素上に存在していることになります。 コンテナ注釈内の注釈は存在しないとみなされるため、「繰返し可能な注釈インタフェース」を適切に処理するには、プロセッサの「サポートされている注釈インタフェース」セットに繰返し可能な注釈インタフェースとそれを含む注釈インタフェースの両方を含めることをお薦めします。

"*"をサポートするプロセッサが trueを返すと、すべての注釈が要求されます。 したがって、たとえば、追加の妥当性チェックの実装に使用される汎用プロセッサは、falseを返すべきです。そうすれば、ほかのそのようなチェッカの実行を妨げずにすみます。

あるプロセッサがキャッチされない例外をスローすると、ツールは、ほかのアクティブな注釈プロセッサを中止する可能性があります。 あるプロセッサがエラーを発行すると、現在のラウンドは終了し、後続のラウンドが、エラーが発行されたことを通知します。 注釈プロセッサは協調的な環境内で実行されるため、キャッチされない例外をプロセッサからスローするのは、エラーの復旧や報告が実行不可能な場合に限るべきです。

ツール環境は、ラウンドごとに、あるいはラウンドをまたがって、マルチ・スレッド方式で環境リソースにアクセスする注釈プロセッサをサポートする必要はありません。

注釈プロセッサに関する構成情報を返すメソッドがnullを返したか、その他の無効な入力を返したか、あるいは例外をスローした場合、ツール・インフラストラクチャはそれをエラー状態とみなします。

ある注釈プロセッサをさまざまなツール実装内で実行させる場合、その動作を安定させるには、そのプロセッサは次の特性を備えているべきです。

  1. ある入力の処理結果がほかの入力の存在有無に依存しない(直交性)。
  2. 同じ入力を処理した場合には同じ出力が得られる(一貫性)。
  3. 入力Aを処理したあとに入力Bを処理することと、BのあとにAを処理することが、等価である(交換性)。
  4. ある入力の処理が、ほかの注釈プロセッサからの出力の存在に依存しない(独立性)。

Filerインタフェースでは、プロセッサがどのようにファイルを操作できるかに関する制限について説明しています。

APIのノート:
このインタフェースの実装者は、このインタフェースを直接実装するのではなく、AbstractProcessorを拡張すると便利です。
導入されたバージョン:
1.6