Realm-java: Add support for incremental annotation with Gradle 4.7

Created on 18 Apr 2018 · 8Comments · Source: realm/realm-java

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).

O-Community T-Feature

Source

NitroG42

👍23

Most helpful comment

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

bakua on 1 Oct 2018

👍7

All 8 comments

Yes, we should definitely look into this.

cmelchior on 20 Apr 2018

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

Zhuinden on 20 Apr 2018

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 😉

cmelchior on 20 Apr 2018

❤2

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?