JDK-8176714 : javac is wrongly assuming that field JCMemberReference.overloadKind has been assigned to
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-03-14
  • Updated: 2017-05-12
  • Resolved: 2017-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9
10Fixed 9 b163Fixed
Related Reports
Blocks :  
JDK-8173057 - Better disambiguation for functional expressions
Relates :  
JDK-8176878 - ArgumentAttr.argumentTypeCache should be disabled in some cases
Relates :  
JDK-8078093 - Severe compiler performance regression Java 7 to 8 for nested method invocations
Description
In many cases when a method reference is being attributed, a copy of the tree is created and that copy is the one that is attributed. Field overloadKind is set for a copy of the original tree but it's value is never copied back. Later the compiler assumes that this field has been set when it's actually null
Comments
thanks
24-03-2017
Fix approved.
23-03-2017
More info: Is there a webrev/review available somewhere?
23-03-2017
Fix Request We consider that this bug should be fixed in JDK9 as this is a regression produced by JDK-8078093. Also it's not too hard to reproduce and acceptable code can be rejected by javac. I have attached the fix which makes sure that the overloadKind field is copied between method references, plus it used a local cache in more cases so that the ArgumentAttr.argumentTypeCache won't get affected during speculative attribution.
22-03-2017
priority raised as this is a regression
22-03-2017