elucash
commented
9 years ago We are developing similar annotation processor http://immutables.org, so I had a chance to deal with this problem. In general, you need to generate code with correct type definition, which will get resolved at later compilation step, annotation processing infrastructure should handle that automatically, but here's the thing that need to be done:
- Logic to analyze attribute type should not break at
ErrorTypes. Error type is a variant of DeclaredType but in unresolved state. Javac and ECJ handle error types slightly differently for nested unresolved type arguments though. - If attribute's type is yet-to-be-generated was declared with a simple name, then unresolved type placeholder will know only it's simple name, any import from source java file will be ignored. We managed to get original sources and match imports from there, so in a generated code we present type with correct import or correct fully qualified name.
(see [immutables/issues/93](https://github.com/immutables/immutables/issues/93] for linked commits if needed)
I saw that AutoValue tries to resolve similar cases. There's logic to delay processing of values with unresolved types to later rounds. But, frankly, I think that will work only for some cases, not as a general case solution (thinking of cyclic dependencies etc).
Hope this might help.
Cyclic dependencies between API-linked types generated by other annotation processors (e.g. a FreeBuilder clone) are problematic, as both types need to detect the other is a buildable type before they can complete their API. One solution may be to generate the non-property-dependent parts of the API on round 1, and delay generation of the rest by using the superclass trick a second time (Type.Builder -> Type_Builder -> Type_Builder_Superclass)