RFR: JDK-8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap incorrectly

[Jonathan Gibbons]

Jan,

You don't need to @build JavacTestingAbstractProcessor, since it is not 
used.

Otherwise OK.

-- Jon


On 10/31/18 7:59 AM, Jan Lahoda wrote:
> Hi,
>
> After JDK-8187950, when a Symbol is completed in "user"/external mode 
> (as opposed to "javac internal" mode), and the completion fails, the 
> failed Symbol is "split", so that the user's code and javac may see a 
> different version of the Symbol (e.g. completed/not completed). This 
> helps to prevent throwing CompletionFailures to user's code.
>
> But the issue is that ClassFinder.loadClass may create "speculative" 
> ClassSymbols, which are subsequently removed if they turn out to be 
> non-existent. But when this happens in the "user" mode (like inside 
> Elements.getTypeElement), even these non-existent ClassSymbols are 
> still retained, and the number of ClassSymbols retained this way may 
> be fairly high. The proposed patch is to clear these speculative 
> Symbols even from the "user" mode cache.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209055
> Webrev: http://cr.openjdk.java.net/~jlahoda/8209055/webrev.00/
>
> Any feedback is welcome.
>
> Thanks,
>     Jan