Add support for incremental annotation with Gradle 4.7

[NitroG42]

As Gradle 4.7 is out, there had to be one issue for this :)
The documentation to handle this is here.
I think Realm-java could implement this ? (but I might be wrong as I don't fully understand all the works behind annotation processors).

[cmelchior]

Yes, we should definitely look into this.

[Zhuinden]

Isolating annotation processors

These look at each annotated element in isolation, creating generated files or validation messages for it. For instance an EntityProcessor could create a Repository for each type annotated with @Entity.

Example: An isolated annotation processor

processor/src/main/java/EntityProcessor.java

 Set<? extends Element> entities = roundEnv.getElementsAnnotatedWith(entityAnnotation);
 for (Element entity : entities) {
     createRepository((TypeElement) entity);
 }

Isolating processors have the following limitations:

Can’t read resources

Can’t write resources

Can’t have any side effects except for using the Filer and Messager APIs

Can’t depend on compiler-specific APIs like com.sun.source.util.Trees

Must provide exactly one originating element for each file generated with the Filer API

Must make all decisions about an element based on information reachable from its AST. For instance it can query the super class, method return types etc, but can’t look at other, unrelated elements.

Gradle will recompile the generated file whenever the source file is affected. If the source file is deleted, the generated file is deleted.

Yeah I'm pretty sure generating a per-file __RealmProxy counts as an isolating annotation processor

[cmelchior]

Yep, I did take a quick glance at it. Actually, I think Realm falls into the category of being an aggregating processor as we are writing module files containing all know model classes.

You could argue we are both. Isolating for the proxies and Aggregating for the modules. I will need to go over the docs in more details to see if there is any advantage in splitting up our annotation processor with regard to this, but it will mean partly processing model classes twice which we currently only do once and use the metadata for both proxies and module files.

Fortunately, we already have RUNTIME retention on our annotations. Someone convinced us that was a good idea 😉

[oehme]

Just a quick heads-up: Gradle 4.8 will no longer fail compilation if a processor does something unsupported, but just do a full recompile instead. That should make things more robust.

As for the category: If you create module files by automatically including all models, then yes that would be aggregating. Splitting the processor won't make that faster, since it reacts to the same annotations, so performance will be dominated by the aggregating one. That being said, aggregating is not that bad as long as the number of annotated classes is relatively small compared to the number of total classes in the code base.

Is there anything else I can help with?

[cmelchior]

@oehme Thank you for the clarifications. No, I don't think I have any more questions at this time. If some come up, I'll be sure to ping you 😄

[bakua]

Hello, how are you guys doing with this one, please?

[ArsenSalimov]

Any updates?

[ArtemKleinschmidt]

Hello, are there any updates on incremental build support?