There is a serious mismatch between the use of a context in JavacTaskImpl (which believes there is just one context for the life of the compilation) and JSR269 (which creates a new context for each round of annotation processing.)
This can show up if some 199 user code (eg a DiagnosticListener) calls tree code (eg Trees.instance(CompilationTask) ) which will use the context in the JavacTaskImpl, which has potentially been cleared by JavacProcessingEnvironment.contextForNextRound.
In addition, it is conceptually wrong for JavacTaskImpl to call its endContext as it does, because in the face of 269, that is no longer the "correct" /"active" context.
This can show up if some 199 user code (eg a DiagnosticListener) calls tree code (eg Trees.instance(CompilationTask) ) which will use the context in the JavacTaskImpl, which has potentially been cleared by JavacProcessingEnvironment.contextForNextRound.
In addition, it is conceptually wrong for JavacTaskImpl to call its endContext as it does, because in the face of 269, that is no longer the "correct" /"active" context.
- relates to
-
JDK-6361619 AssertionError from ClassReader
- Closed
-
JDK-6358024 TaskListener should be propagated between processing rounds
- Closed