Interface Processor

Annotation processing happens in a sequence of rounds. On each round, a processor may be asked to process a subset of the annotations found on the source and class files produced by a prior round. The inputs to the first round of processing are the initial inputs to a run of the tool; these initial inputs can be regarded as the output of a virtual zeroth round of processing. If a processor was asked to process on a given round, it will be asked to process on subsequent rounds, including the last round, even if there are no annotations for it to process. The tool infrastructure may also ask a processor to process files generated implicitly by the tool's operation.

Each implementation of a Processor must provide a public no-argument constructor to be used by tools to instantiate the processor. The tool infrastructure will interact with classes implementing this interface as follows:

1. If an existing Processor object is not being used, to create an instance of a processor the tool calls the no-arg constructor of the processor class.
2. Next, the tool calls the init method with an appropriate ProcessingEnvironment.
3. Afterwards, the tool calls getSupportedAnnotationTypes, getSupportedOptions, and getSupportedSourceVersion. These methods are only called once per run, not on each round.
4. As appropriate, the tool calls the process method on the Processor object; a new Processor object is not created for each round.

The tool uses a discovery process to find annotation processors and decide whether or not they should be run. By configuring the tool, the set of potential processors can be controlled. For example, for a JavaCompiler the list of candidate processors to run can be set directly or controlled by a search path used for a service-style lookup. Other tool implementations may have different configuration mechanisms, such as command line options; for details, refer to the particular tool's documentation. Which processors the tool asks to run is a function of the interfaces of the annotations present on the root elements, what annotation interfaces a processor supports, and whether or not a processor claims the annotation interfaces it processes. A processor will be asked to process a subset of the annotation interfaces it supports, possibly an empty set. For a given round, the tool computes the set of annotation interfaces that are present on the elements enclosed within the root elements. If there is at least one annotation interface present, then as processors claim annotation interfaces, they are removed from the set of unmatched annotation interfaces. When the set is empty or no more processors are available, the round has run to completion. If there are no annotation interfaces present, annotation processing still occurs but only universal processors which support processing all annotation interfaces, "*", can claim the (empty) set of annotation interfaces.

An annotation interface is considered present if there is at least one annotation of that interface present on an element enclosed within the root elements of a round. For this purpose, a type parameter is considered to be enclosed by its generic element. For this purpose, a package element is not considered to enclose the top-level classes and interfaces within that package. (A root element representing a package is created when a package-info file is processed.) Likewise, for this purpose, a module element is not considered to enclose the packages within that module. (A root element representing a module is created when a module-info file is processed.) Annotations on type uses, as opposed to annotations on elements, are ignored when computing whether or not an annotation interface is present.

An annotation is present if it meets the definition of being present given in AnnotatedConstruct. In brief, an annotation is considered present for the purposes of discovery if it is directly present or present via inheritance. An annotation is not considered present by virtue of being wrapped by a container annotation. Operationally, this is equivalent to an annotation being present on an element if and only if it would be included in the results of Elements.getAllAnnotationMirrors(Element) called on that element. Since annotations inside container annotations are not considered present, to properly process repeatable annotation interfaces, processors are advised to include both the repeatable annotation interface and its containing annotation interface in the set of supported annotation interfaces of a processor.

Note that if a processor supports "*" and returns true, all annotations are claimed. Therefore, a universal processor being used to, for example, implement additional validity checks should return false so as to not prevent other such checkers from being able to run.

If a processor throws an uncaught exception, the tool may cease other active annotation processors. If a processor raises an error, the current round will run to completion and the subsequent round will indicate an error was raised. Since annotation processors are run in a cooperative environment, a processor should throw an uncaught exception only in situations where no error recovery or reporting is feasible.

The tool environment is not required to support annotation processors that access environmental resources, either per round or cross-round, in a multi-threaded fashion.

If the methods that return configuration information about the annotation processor return null, return other invalid input, or throw an exception, the tool infrastructure must treat this as an error condition.

To be robust when running in different tool implementations, an annotation processor should have the following properties:

1. The result of processing a given input is not a function of the presence or absence of other inputs (orthogonality).
2. Processing the same input produces the same output (consistency).
3. Processing input A followed by processing input B is equivalent to processing B then A (commutativity)
4. Processing an input does not rely on the presence of the output of other annotation processors (independence)

The Filer interface discusses restrictions on how processors can operate on files.