Third parties may wish to provide value-add wrappers around the facility objects from this interface, for example a {@code Filer} extension that allows multiple processors to coordinate writing out a single source file. To enable this, for processors running in a context where their side effects via the API could be visible to each other, the tool infrastructure must provide corresponding facility objects that are {@code .equals}, {@code Filer}s that are {@code .equals}, and so on. In addition, the tool invocation must be able to be configured such that from the perspective of the running annotation processors, at least the chosen subset of helper classes are viewed as being loaded by the same class loader. (Since the facility objects manage shared state, the implementation of a wrapper class must know whether or not the same base facility object has been wrapped before.)
Joseph - D. DarcyScott - SeligmanPeter - von der Ahé1.6 - | Method from javax.annotation.processing.ProcessingEnvironment Summary: |
|---|
| getElementUtils, getFiler, getLocale, getMessager, getOptions, getSourceVersion, getTypeUtils |
| Method from javax.annotation.processing.ProcessingEnvironment Detail: |
|---|
|
|
|
|
See documentation of the particular tool infrastructure being used for details on how to pass in processor-specific options. For example, a command-line implementation may distinguish processor-specific options by prefixing them with a known string like {@code "-A"}; other tool implementations may follow different conventions or provide alternative mechanisms. A given implementation may also provide implementation-specific ways of finding options passed to the tool in addition to the processor-specific options. |
|
|