Actually, reading this response, I think you are right, and I went on an overly complicated tangent debugging this.
Like you said, android.jar doesn't have javax.lang.model.element.Modifier enum. Now, in our build, we actually add a number of rt.jar classes to the -Xbootclasspath of the javac JVM. So, I was seeing it being loaded from custom Error Prone plugins and available to the compiler during debugging, and that caused me to become confused.
However, I just realized that - of course! - javac would be looking for it in the classpath of the code being compiled, not on the compiler's classpath, since the problem happens when processing an annotation (@Var) that is included with the compiled code. This is 100% unrelated to whether Modifier is available to the compiler and compiler plugins and related only to whether it's available to the compiled Java project.
Short term, we could possibly fix this by taking that enum into its own jar and adding it as a dependency, then removing it (and the annotations using it) before dexing. That said, would this be considered a bug on the Error Prone side?
By default, when running with -Werror, this breaks the Var checker for Android projects since at least 2.3.3, and it breaks LazyInit
since 2.3.4 (see this
Thanks so much for these! As noted above, the actual issue might be unrelated, but it's not the first time I search for that.
We build all targets with -Werror. I also looked for a way to suppress that diagnostic and only that diagnostic. Thus far, I haven't figured out how to do that.
Is this a case where it would be worth it to open an issue on EP for Android support for @Var/@LazyInit/etc out of the box?