42 * processing are the initial inputs to a run of the tool; these
43 * initial inputs can be regarded as the output of a virtual zeroth
44 * round of processing. If a processor was asked to process on a
45 * given round, it will be asked to process on subsequent rounds,
46 * including the last round, even if there are no annotations for it
47 * to process. The tool infrastructure may also ask a processor to
48 * process files generated implicitly by the tool's operation.
49 *
50 * <p> Each implementation of a {@code Processor} must provide a
51 * public no-argument constructor to be used by tools to instantiate
52 * the processor. The tool infrastructure will interact with classes
53 * implementing this interface as follows:
54 *
55 * <ol>
56 *
57 * <li>If an existing {@code Processor} object is not being used, to
58 * create an instance of a processor the tool calls the no-arg
59 * constructor of the processor class.
60 *
61 * <li>Next, the tool calls the {@link #init init} method with
62 * an appropriate {@code ProcessingEnvironment}.
63 *
64 * <li>Afterwards, the tool calls {@link #getSupportedAnnotationTypes
65 * getSupportedAnnotationTypes}, {@link #getSupportedOptions
66 * getSupportedOptions}, and {@link #getSupportedSourceVersion
67 * getSupportedSourceVersion}. These methods are only called once per
68 * run, not on each round.
69 *
70 * <li>As appropriate, the tool calls the {@link #process process}
71 * method on the {@code Processor} object; a new {@code Processor}
72 * object is <em>not</em> created for each round.
73 *
74 * </ol>
75 *
76 * If a processor object is created and used without the above
77 * protocol being followed, then the processor's behavior is not
78 * defined by this interface specification.
79 *
80 * <p> The tool uses a <i>discovery process</i> to find annotation
81 * processors and decide whether or not they should be run. By
82 * configuring the tool, the set of potential processors can be
|
42 * processing are the initial inputs to a run of the tool; these
43 * initial inputs can be regarded as the output of a virtual zeroth
44 * round of processing. If a processor was asked to process on a
45 * given round, it will be asked to process on subsequent rounds,
46 * including the last round, even if there are no annotations for it
47 * to process. The tool infrastructure may also ask a processor to
48 * process files generated implicitly by the tool's operation.
49 *
50 * <p> Each implementation of a {@code Processor} must provide a
51 * public no-argument constructor to be used by tools to instantiate
52 * the processor. The tool infrastructure will interact with classes
53 * implementing this interface as follows:
54 *
55 * <ol>
56 *
57 * <li>If an existing {@code Processor} object is not being used, to
58 * create an instance of a processor the tool calls the no-arg
59 * constructor of the processor class.
60 *
61 * <li>Next, the tool calls the {@link #init init} method with
62 * an appropriate {@link ProcessingEnvironment}.
63 *
64 * <li>Afterwards, the tool calls {@link #getSupportedAnnotationTypes
65 * getSupportedAnnotationTypes}, {@link #getSupportedOptions
66 * getSupportedOptions}, and {@link #getSupportedSourceVersion
67 * getSupportedSourceVersion}. These methods are only called once per
68 * run, not on each round.
69 *
70 * <li>As appropriate, the tool calls the {@link #process process}
71 * method on the {@code Processor} object; a new {@code Processor}
72 * object is <em>not</em> created for each round.
73 *
74 * </ol>
75 *
76 * If a processor object is created and used without the above
77 * protocol being followed, then the processor's behavior is not
78 * defined by this interface specification.
79 *
80 * <p> The tool uses a <i>discovery process</i> to find annotation
81 * processors and decide whether or not they should be run. By
82 * configuring the tool, the set of potential processors can be
|