Any way to run the processor before the compiler throws an error?

Question

Hi,
I want to generate code for an annotation @OverrideAll that would implement all the interface I methods with some default body.:
Example
interface I {
  void method();
@OverrideAll
class A implements I {
}would have to generate code like this:
class A_gen implements I {
  public void method() {
class A extends A_gen {}However, I have the problem that the original source file does NOT compile because the interface I is not implemented, and as such, the annotation processor never runs. My question is:
Is there any way I could force the annotation processor to run before the compiler shows the error? Or at least some way to supress this error message and give a chance to the annotation processor to run?
TIA,
Gabriel

Answer 1

belingueres wrote:
Hi,
Thanks for answering so soon.
I would prefer not to name the generated class in the original source code. As an alternative I thought to rather generate a subclass, but then there is the instantiation problem (can´t do it without creating a factory method in class A and making it abstract, and indeed again need to name the generated class):
@OverrideAll
abstract class A implements I {
public static A create() {
return new A_gen();
// generated class
class A_gen extends A {
public void method() {
}so it seems I reached a dead end here.
It would really help if (using the superclass generation as originally posted) I could change in the processor the superclass of class A to be A_gen, but it would require AST rewritting and I guess it is not a good option (if at all possible.)Belingueres,There are two ways to do what you want. You can either generate a superclass of A, or a subclass of A.
If you generate a superclass, you need to specify the generated superclass's name in the extends clause of A. But you said "I would prefer not to name the generated class in the original source code", but give no reasons then go off exploring the second alternative.
If you generate a subclass of A, then you need a way for the rest of the code to instantiate As without really knowing about the subclass, so you do in fact need a factory method in A which actually returns A_gens.
I suggest you revisit your preference for not naming the generated class, and work out why you have that preference, and whether it is actually a sound engineering constraint, an aesthetic nicety (maybe in terms of not wanting the implemention strategy to be brought to the surface) or something emotional.
You can do what you want with annotation processing, but you must choose between naming the generated superclass in the extends, or having an factory method that names the subclass.
A related issue is that if you generate the superclass, the annotation processor can pick up the name of the class to be generated from the "extends" clause, and you therefore don't need to specify it any other way, whereas if you generate a subclass, the annotation processor cannot infer the name of the subclass that is being instantiated from the factory method (unless you use non standard APIs in your annotation processor), which means you need to explicitly name it as an attribute of the annotation.
I have a preference for generating a superclass because that imposes less restrictions on whatever else you do with the class, and less of the code generation implementation details leak up into the class's signature.
Also note when generating a superclass, if you want to extend something other than Object, then you need to specify that as an annotation value, usually as a Class<?>.
Bruce