I am very surprised to find that javac does not print the stack trace of exceptions that are thrown by annotation processors, not even in -verbose mode. Nor does it tell me which annotation processor threw the exception. Given below is an example of javac output in -verbose mode:
Round 1:
input files: {sahoo.EmploymentRecord}
annotations: [javax.persistence.Embeddable]
last round: false
error: Exception thrown while constructing Processor object: java.lang.NullPointerException

What's harm in printing more details about the exception?

Sahoo

 

 

This is a known issue.

If you are developing an annotation processor, you want to see the stack trace. But if someone else is running your buggy annotation processor, then they probably don't want to see it. At the moment javac does not know what sort of user you are. I think there is a desire to address this at some point. The thinking is that the terse mode would be normal, but processor developers could use a command line switch to enable full stack trace output. At least it is better than it was, javac used to report Exceptions from processors as though they were bugs in javac and asked the user to file a bug with Sun!

Actually, in the case you posted, the exception was not thrown while running the processor, but while constructing it. Check your default constructor, and initializers.

 

 

Bruce is correct. While writing the javac implementation of JSR 269, we had internal discussion over how to handle such issues. Since we assumed there would be many more people running annotation processors rather than developing them, by default the stack trace is not shown. Bug 6401798 "Add -Xlint=developer option to help debug annotation processing issues" was filed to track the need to provide more detailed information to annotation processor developers.

 

 

This is not your case, but I have in the past wrapped my whole process method in a try {} catch (exception e) {} block in order to print out an exception to find exactly where it was coming from, not ideal, but it does the trick.

Though as I said, for your case it seems to be somewhere in the constructor / initializers. You could just try constructing a new instance inside a main() method in a temporary class, and see if that sheds any light on your problem.

Bruce

 

 

The exception was coming from @Override init(). Yes, I know wrapping the whole method body with try catch (Exception e) does the trick and that's what I have done in my code; I thought I mentioned it while posting the original question. Having said that I would love to see the RFE #6401798 being addressed in some future release.

Thanks,
Sahoo