Community
Participate
Working Groups
M4 I wanted to make use of the new compilation participant extension point however I have problems to get it to work. Here is what I am trying to do: - I want to process annotations inside a file (but without providing an annotation processor that depends on APT) - I therefore registered a compilation participant. The participant returns true in isAnnotationProcessor. However this results in the fact that the compilation participant is only invoked for source files (e.g the method processAnnotations is called) that define annotations NOT for those referencing annotations. Shouldn't the method be called for file referencing annotations as well? I tested it with: package p; public @interface Anno { } For this file the method processAnnotations is called. However for the following file it isn't @Anno public class A { String field; }
It looks like that JDT/Core has already created a compiler AST when passing control over to the compilation participant (when in annotation processor mode). Given this wouldn't it make sense that: - the participant (if an annotation processor) gets a list of fully qualified types names of the annotations used in the file. This would avoid building an AST to figure out if the participant is interested in the file at all. Or even better a list of ITypeBinding representing the used annotations. - currently there is no API to create an DOM AST based on the already existing compiler AST. Creating the DOM AST using the normal API will create the compiler AST again. Wouldn't it make sense that we have API to create a DOM AST on the already existing compiler AST. Since the participant reports back the files it touches JDT/Core could even invalidate the compiler AST in a smart way so that the next participant gets a new AST.
Dirk - take a look at the latest please. As for your questions in comment #1, the builder only talks to the participants before/after a compile loop, not in the middle when the ASTs are available.
Kent, I looked at the code from HEAD and I think there are still some problems. The participant is now invoked when in annotation processor mode, however the flag hasAnnotations on ICompilationParticipantResult is always false. Digging around a little in the code I found that the flag is computed in CompilationUnitDeclaration#cleanUp. The code there only inspects the type declarations if they are annotations. Shouldn't the code walk the AST to find out if an annotation is referenced ? Have you thought about the idea passing a list of qualified type names of referenced annotations to the ICompilationParticipantResult. This would allow easy detection (without building an AST) whether the participant is interested or not. Regarding the DOM/AST creation: I wasn't aware that the processor is call at the end of the loop. However I still think that having API on ICompilationParticipantResult to create (and share) an AST would be an advantage in terms of speed. The AST could be shared accross different participants and using the information about newly created and changed CUs passed back to the builder the AST could even be invalidated. But having such API would require that the loops are changed. Each ICompilationParticipantResult must then be passed to all participants. Otherwise we would have to many ASTs in memory. Thoughts ?
The flag is also set any time annotations are stored on a type/method/field binding. Check again with latest (small bug as to when it was set). We don't expect many participants to be attached at the same time so creating numerous ASTs should not be an issue. With APT, most annotation processing will go thru them. If you're only interested in certain annotations, then why not scan the source for the simple name before creating the AST?
Dirk, please reopen if/when you find anything else. Added ParticipantBuildTests.
Kent, regarding your question why not scanning the file: the problem is that I have to match fully qualified names.
But type names (last segment of any qualified name) are 'usually' unique, so just scan for them. You should not have too many false positives.
Verified for 3.2 M5 using build I20060214-0010
