RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure.

[Liam Miller-Cushon]

Another thing - I think the patch needs to set the deferred completion
failure handler before calling processor.init (in the constructor
for ProcessorState).

I'm seeing unhandled CompletionFailures with stack traces like the
following. (I was testing the patch on JDK 9 so the line numbers are a
little off.)

java.lang.RuntimeException:
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
android.view.View not found
at
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:163)
...
Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file
for android.view.View not found
at
jdk.compiler/com.sun.tools.javac.code.ClassFinder.newCompletionFailure(ClassFinder.java:386)
...
at
jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:84)
...
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:679)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:778)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:873)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:110)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1213)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1322)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1225)
...

On Mon, Feb 12, 2018 at 10:50 AM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Hi Jan,
>
> I've run into the same problem a few times, and made some half-baked
> experiments around not caching completion failures [1]. The approach you
> describe sounds good to me. Also,
> * this will fix JDK-8177436 [2] too
> * there's a minor typo in the javadoc for DeferredCompletionFailureHandler
> - "throw the the client code"
>
> [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017
> -March/010883.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8177436
>
> On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>> Hi,
>>
>> Currently, when a calling some API methods, the client (e.g.
>> TaskListener, an annotation Processor or a JavacTask client) may get a
>> CompletionFailure, if the given Symbol was not completed yet. This is not
>> only problematic for the clients, but if the client catches and ignores the
>> exception, the javac may be unable to report an appropriate error.
>>
>> The proposed patch here:
>> -separates "user " and "javac" modes, in which CompletionFailure handling
>> differs a bit
>> -in javac mode, CompletionFailures should be handled as they are currently
>> -in user (code) mode, when a CompletionFailure is thrown (and would go
>> outside of an API method), the API method will suppress the exception, and
>> the Symbol's state (completer, kind, type) will be restored to original
>> when the mode is switched back to javac mode. If the Symbol is then
>> completed again inside javac, the CompletionFailure is thrown again and the
>> appropriate errors are reported.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187950
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/
>>
>> How does this look?
>>
>> Thanks,
>>     Jan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180212/9658b36c/attachment-0001.html>