Joe Darcy joe.darcy at oracle.com
Mon Jul 22 23:37:54 UTC 2019

Hi Ron,

I take it you aren't finding


to be sufficient? This will indicate an error has been raised started at 
the *next* round of annotation processing.

I would be more tempted to add some default methods like

  * warn/printWarn(CharSequence msg)
  * warn/printWarn(CharSequence msg, Element e)
  * error/printError(CharSequence msg)
  * error/printError(CharSequence msg, Element e)



On 7/19/2019 1:09 PM, Ron Shapiro wrote:
> In a number of processors that I've implemented, I've wanted to wrap a 
> Messager instance to track if I've printed a diagnostic with an ERROR 
> kind so I can know to abort any generation if the inputs are invalid.
> There are a number of ways to do this, but what always feels like 
> would be most natural is to be able to create a ForwardingMessager of 
> some sort. I think the easiest way to do this is if there were already 
> an AbstractMessager class, so I wanted to propose adding it to the JSR 
> 269 APIs.
> The implementation would be rather simple, just telescoping the calls 
> with `null` arguments, just like JavacMessager works.
> @Override
> public void printMessage(Diagnostic.Kind kind, CharSequence msg) {
>     printMessage(kind, msg, null);
> }
> @Override
> public void printMessage(Diagnostic.Kind kind, CharSequence msg, 
> Element e) {
>     printMessage(kind, msg, e, null);
> }
> // etc
> Alternatively, the methods could become default methods, which is 
> probably the easiest change and doesn't introduce a new type.
> Does something like this make sense?

More information about the compiler-dev mailing list