<div dir="ltr">Another thing - I think the patch needs to set the deferred completion failure handler before calling processor.init (in the constructor for ProcessorState).<div><br></div><div>I'm seeing unhandled CompletionFailures with stack traces like the following. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(I was testing the patch on JDK 9 so the line numbers are a little off.)</span><div><br></div><div><div>java.lang.RuntimeException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for android.view.View not found</div><div><span style="white-space:pre">  </span>at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:163)</div><div>...</div><div>Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for android.view.View not found</div><div><span style="white-space:pre">       </span>at jdk.compiler/com.sun.tools.javac.code.ClassFinder.newCompletionFailure(ClassFinder.java:386)</div><div>...</div><div><span style="white-space:pre">     </span>at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:84)</div><div>...</div><div><span style="white-space:pre">       </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:679)</div><div><span style="white-space:pre">    </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:778)</div><div><span style="white-space:pre">       </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:873)</div><div><span style="white-space:pre">    </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:110)</div><div><span style="white-space:pre">    </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1213)</div><div><span style="white-space:pre">     </span>at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1322)</div><div><span style="white-space:pre">  </span>at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1225)</div></div><div>...</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 12, 2018 at 10:50 AM, Liam Miller-Cushon <span dir="ltr"><<a href="mailto:cushon@google.com" target="_blank">cushon@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Jan,</div><div><br></div><div>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,</div><div><div>* this will fix JDK-8177436 [2] too</div><div>* there's a minor typo in the javadoc for DeferredCompletionFailureH<wbr>andler - "throw the the client code"<br></div></div><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255);float:none;display:inline">[1] </span><a href="http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html" class="m_-4577931065450942716m_4571143415463393745m_4703939707348298493gmail-m_-6973185364403339529gmail-cremed m_-4577931065450942716m_4571143415463393745m_4703939707348298493gmail-m_-6973185364403339529gmail-cremed m_-4577931065450942716m_4571143415463393745m_4703939707348298493gmail-m_-6973185364403339529cremed m_-4577931065450942716m_4571143415463393745m_4703939707348298493gmail-cremed m_-4577931065450942716m_4571143415463393745m_4703939707348298493cremed m_-4577931065450942716m_4571143415463393745cremed m_-4577931065450942716cremed" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)" target="_blank">http://mail.openjdk.java.n<wbr>et/pipermail/compiler-dev/2017<wbr>-March/010883.html</a><br></div><div>[2] <a href="https://bugs.openjdk.java.net/browse/JDK-8177436" class="m_-4577931065450942716gmail-m_4571143415463393745m_4703939707348298493m_-6973185364403339529gmail-cremed m_-4577931065450942716gmail-m_4571143415463393745m_4703939707348298493m_-6973185364403339529gmail-cremed m_-4577931065450942716gmail-m_4571143415463393745m_4703939707348298493m_-6973185364403339529cremed m_-4577931065450942716gmail-m_4571143415463393745m_4703939707348298493cremed m_-4577931065450942716gmail-m_4571143415463393745cremed m_-4577931065450942716gmail-cremed m_-4577931065450942716cremed" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)" target="_blank">https://bugs.openjdk.java.<wbr>net/browse/JDK-8177436</a></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <span dir="ltr"><<a href="mailto:jan.lahoda@oracle.com" target="_blank">jan.lahoda@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
The proposed patch here:<br>
-separates "user " and "javac" modes, in which CompletionFailure handling differs a bit<br>
-in javac mode, CompletionFailures should be handled as they are currently<br>
-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.<br>
<br>
Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8187950" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8187950</a><br>
Webrev: <a href="http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jl<wbr>ahoda/8187950/webrev.00/</a><br>
<br>
How does this look?<br>
<br>
Thanks,<br>
    Jan<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>