Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Java™ Platform Standard Ed. 6 |
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface Processor
The interface for an annotation 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:
Processor
object is not being used, to
create an instance of a processor the tool calls the no-arg
constructor of the processor class.
init
method with
an appropriate ProcessingEnvironment
.
getSupportedAnnotationTypes
, getSupportedOptions
, and getSupportedSourceVersion
. These methods are only called once per
run, not on each round.
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 what annotations are present on the root elements, what annotation types a processor
processes, and whether or not a processor claims the annotations it processes. A processor will be asked to
process a subset of the annotation types it supports, possibly an
empty set.
For a given round, the tool computes the set of annotation types on
the root elements. If there is at least one annotation type
present, as processors claim annotation types, they are removed
from the set of unmatched annotations. When the set is empty or no
more processors are available, the round has run to completion. If
there are no annotation types present, annotation processing still
occurs but only universal processors which support
processing "*"
can claim the (empty) set of annotation
types.
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:
The Filer
interface discusses restrictions on how
processors can operate on files.
Note that implementors of this interface may find it convenient
to extend AbstractProcessor
rather than implementing this
interface directly.
Method Summary | |
---|---|
Iterable<? extends Completion> |
getCompletions(Element element,
AnnotationMirror annotation,
ExecutableElement member,
String userText)
Returns to the tool infrastructure an iterable of suggested completions to an annotation. |
Set<String> |
getSupportedAnnotationTypes()
Returns the names of the annotation types supported by this processor. |
Set<String> |
getSupportedOptions()
Returns the options recognized by this processor. |
SourceVersion |
getSupportedSourceVersion()
Returns the latest source version supported by this annotation processor. |
void |
init(ProcessingEnvironment processingEnv)
Initializes the processor with the processing environment. |
boolean |
process(Set<? extends TypeElement> annotations,
RoundEnvironment roundEnv)
Processes a set of annotation types on type elements originating from the prior round and returns whether or not these annotations are claimed by this processor. |
Method Detail |
---|
Set<String> getSupportedOptions()
getOptions
.
Each string returned in the set must be a period separated sequence of identifiers:
- SupportedOptionString:
- Identifiers
- Identifiers:
- Identifier
- Identifier
.
Identifiers
- Identifier:
- Syntactic identifier, including keywords and literals
A tool might use this information to determine if any options provided by a user are unrecognized by any processor, in which case it may wish to report a warning.
SupportedOptions
Set<String> getSupportedAnnotationTypes()
"*"
by itself represents the set of all annotation types,
including the empty set. Note that a processor should not
claim "*"
unless it is actually processing all files;
claiming unnecessary annotations may cause a performance
slowdown in some environments.
Each string returned in the set must be accepted by the following grammar:
where TypeName is as defined in the Java Language Specification.
- SupportedAnnotationTypeString:
- TypeName DotStaropt
- *
- DotStar:
- . *
SupportedAnnotationTypes
SourceVersion getSupportedSourceVersion()
SupportedSourceVersion
,
ProcessingEnvironment.getSourceVersion()
void init(ProcessingEnvironment processingEnv)
processingEnv
- environment for facilities the tool framework
provides to the processorboolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv)
true
is returned, the annotations are claimed and subsequent
processors will not be asked to process them; if false
is returned, the annotations are unclaimed and subsequent
processors may be asked to process them. A processor may
always return the same boolean value or may vary the result
based on chosen criteria.
The input set will be empty if the processor supports "*"
and the root elements have no annotations. A Processor
must gracefully handle an empty set of annotations.
annotations
- the annotation types requested to be processedroundEnv
- environment for information about the current and prior round
Iterable<? extends Completion> getCompletions(Element element, AnnotationMirror annotation, ExecutableElement member, String userText)
int
member whose value should lie between 1
and 10 or a string member that should be recognized by a known
grammar, such as a regular expression or a URL.
Since incomplete programs are being modeled, some of the
parameters may only have partial information or may be null
. At least one of element
and userText
must be non-null
. If element
is non-null
, annotation
and member
may be null
. Processors may not throw a NullPointerException
if some parameters are null
; if a processor has no
completions to offer based on the provided information, an
empty iterable can be returned. The processor may also return
a single completion with an empty value string and a message
describing why there are no completions.
Completions are informative and may reflect additional validity checks performed by annotation processors. For example, consider the simple annotation:
(A Mersenne prime is prime number of the form 2n - 1.) Given an@MersennePrime { int value(); }
AnnotationMirror
for this annotation type, a list of all such primes in the
int
range could be returned without examining any other
arguments to getCompletions
:
A more informative set of completions would include the number of each prime:import static javax.annotation.processing.Completions.*; ... return Arrays.asList(of
("3"), of("7"), of("31"), of("127"), of("8191"), of("131071"), of("524287"), of("2147483647"));
However, if thereturn Arrays.asList(of
("3", "M2"), of("7", "M3"), of("31", "M5"), of("127", "M7"), of("8191", "M13"), of("131071", "M17"), of("524287", "M19"), of("2147483647", "M31"));
userText
is available, it can be checked
to see if only a subset of the Mersenne primes are valid. For
example, if the user has typed
@MersennePrime(1
the value of userText
will be "1"
; and only
two of the primes are possible completions:
Sometimes no valid completion is possible. For example, there is no in-range Mersenne prime starting with 9:return Arrays.asList(of("127", "M7"), of("131071", "M17"));
@MersennePrime(9
An appropriate response in this case is to either return an
empty list of completions,
or a single empty completion with a helpful messagereturn Collections.emptyList();
return Arrays.asList(of("", "No in-range Mersenne primes start with 9"));
element
- the element being annotatedannotation
- the (perhaps partial) annotation being
applied to the elementmember
- the annotation member to return possible completions foruserText
- source code text to be completed
|
Java™ Platform Standard Ed. 6 |
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Copyright 2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Also see the