Community
Participate
Working Groups
Java 5 annotation processors are executed during reconcile as well as during build, if the corresponding setting is enabled. However, Java 6 processors are only executed during build. The functionality should be the same as for Java 5: that is, they should be allowed to report errors during reconcile if reconcile-time processing is enabled, and they should be allowed to generate and delete types during reconcile if they return the AptPreferenceConstants.RTTG_ENABLED_OPTION string in their supportedOptions() implementation.
My current feeling is that this feature should NOT be implemented. Experience to date is that the overwhelming majority of annotation processors are too slow to run in reconcile. In fact, it is quite difficult to make an efficient annotation processor, with either the JSR269 or com.sun.mirror APIs; these APIs are based around the idea of a batch compiler that can build up a complete model of the typesystem and then present it to processors, and that is simply not true in the incremental compilation environment of an IDE. As a result, there are many "trip points" at which a seemingly innocuous call by a processor - e.g., getPackage("com.foo") - can either fail or require the equivalent of a full build before it returns. The difference between a fast and a slow call is hard to explain to a processor writer, and may not even be consistent from version to version, since it depends on technical details of the compiler internals. The upshot of this is that injecting annotation processing into the reconcile phase is likely to (and, in practice, does) result in unpredictable and unacceptable slowdown of the editing experience. The benefits, on the other hand, are dubious; there are few real-world use cases of validation annotation processors that are efficiently realizable.
Marking as P5/enhancement to reflect my feeling that this is undesirable. I'll leave the bug open, as a placeholder for discussion in case anyone feels otherwise.
For the records, this bug is mentioned in the readme. If there hasn't been any response for six years, I wonder if we should close this as wontfix and remove it from the readme?
*Eight* years. I agree. Jay, can you remove it from the readme? (I don't have git set up...) And then let's mark this as WONTFIX.
I just skim read, but especially if is just related to Java 6 level, I agree it should be removed from readme and marked as won't fix. I doubt if too many people will be using Neon code to develop Java 6 apps. (A few might, but the readme does not need to cover each and every bug. :)
It was referring to Java 6 as opposed to Java 5 :-) Java 7 etc. behave just like Java 6 in this regard. But the issue is the same: executing a real-world annotation processor during reconcile is just not performant or safe. We never supported it; no one complained; let's make it official.
Thanks David and Walter. Marking as resolved and will update the readme accordingly.
Hello, looks like this broke my build. I have a Java 7 project that mainly depends on Adrian Walker's Multiline annotation. Before upgrading Mars to Neon I could launch Tomcat with annotation processor enabled and it worked like a charm. Now I can't even start my project. Actually (after a lot of back and forth with other developers) the code self-checks that annotated members are actually populated at early startup, otherwise throwing an exception you would otherwise notice after a few minutes of usage. So, for sake of precision, the project gets compiled but I get an immediate self-thrown Exception on startup rather than a NullPointerException later I don't know how to work this around. If I compile the project with javac it works great, but I need to debug in Tomcat often to perform my daily work. Any ideas?
(In reply to Antonio Anzivino from comment #8) > Hello, > > looks like this broke my build. Antonio, there was nothing done for this, except removing it from the list of know issues in the readme. Are you referring to some other bug perhaps?
Hi, from the readme it was my understanding that you actually removed a feature. Now I understand the meaning of @Walter's "we never supported it; let's make it official". But then I don't fully understand why did the annotation processor work on Mars.1 so I could launch Tomcat with annotation-processed classes. Do you have any ideas on how to investigate? Should I open a different issue? Thanks.
(In reply to Antonio Anzivino from comment #10) > Should I open a different issue? Yes, please open a new bug with steps to reproduce. If possible, please provide a standalone testcase, which will speed up our investigation.
Antonio, this item only regards *reconcile time* processing - that is, as you are typing in an editor, before you hit "save". If you are having problems with build-time processing - that is, when you save and compile - that is a different issue. Back in 2007, there was an idea that we could treat annotation processing much like compilation of the unit being edited. If you typed an annotation, we could process it in realtime and give you an error from the annotation processor as it was being typed. That turned out to be fantasy. Annotation processors are just not fast enough; too many of them need to navigate the entire typesystem, that is, they need to dig into jar files and find things like "all the annotations in classes in package x.y.z". Without major rearchitecting, and much more memory consumption, there is no way to support that.
