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

[Jan Lahoda]

On 12.2.2018 21:26, Liam Miller-Cushon wrote:
> Another thing - I think the patch needs to set the deferred completion
> failure handler before calling processor.init (in the constructor
> for ProcessorState).

Oops, right. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01/

Thanks for the feedback,
     Jan

>
> 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
> <mailto: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
>     <http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html>
>     [2] https://bugs.openjdk.java.net/browse/JDK-8177436
>     <https://bugs.openjdk.java.net/browse/JDK-8177436>
>
>     On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com
>     <mailto: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
>         <https://bugs.openjdk.java.net/browse/JDK-8187950>
>         Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/
>         <http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/>
>
>         How does this look?
>
>         Thanks,
>              Jan
>
>
>