RFR: JDK-8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap incorrectly
jonathan.gibbons at oracle.com
Wed Nov 7 21:34:39 UTC 2018
You don't need to @build JavacTestingAbstractProcessor, since it is not
On 10/31/18 7:59 AM, Jan Lahoda wrote:
> 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.
More information about the compiler-dev