EVALUATION
Short term fix being tracked with 6441871
|
|
|
SUGGESTED FIX
A possible short term fix would be to handle CompletionFailure at the top level and turn it into a friendly error message; not the scary OhMyGod-send-us-a-bug-report message.
|
|
|
EVALUATION
Dealing with completion errors in JSR 269 in general
requires some additional amount of pondering.
Currently, completion errors can be thrown from any place
in the API.
We might not be able to deal with this issue before Mustang
beta 2 as we didn't recognize the scope of this problem earlier.
|
|
|
SUGGESTED FIX
I think we need to rethink completion errors completely.
I have some sketchy ideas:
Make javac operate in two modes:
1. completion errors are fatal
2. completion errors are swallowed and errorneous objects
are returned instead.
Mode 1 should be used for normal batch operation. Mode 2 should
be used when in API mode, that is, called from annotation processor
or Tree API.
If this is confusing, don't worry, we will discuss it in person.
|
|
|
EVALUATION
Note: To run the test program I needed to declare this annotation type:
@interface usethis { String value() default ""; }
The error that's reported is correct: the processor really does create a bad
class file. In round 1 it creates a class file named newfile.class
that is completely empty. In round 2 it tries (as it should) to read
that empty class file, and fails.
The "bad class file" should, however, be reported as an error message
rather than as a javac crash.
|
|
|
Java