JDK-7132880 : Resolve should support nested resolution contexts
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2012-01-24
  • Updated: 2012-09-28
  • Resolved: 2012-03-19
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 8
8 b30Fixed
Description
A lambda expression can cause overload resolution to run recursively - consider the following case where we havea lambda in method context:

m(x->x.size())

Here we have an 'outer' call context, for 'm' - when a suitable overload candidate is found, the lambda needs to be attributed using that candidate's formal as target type - this means that we effectively recursively step into overload resolution (this time for x.size()). Resolve.java should be able to handle nested resolution context.
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/161230ec7c73
02-03-2012
EVALUATION Yes, each overload resolution process should create its own resolution context, and operate only on variables of that very same context, to avoid propagation of side-effects (i.e. eror messages, etc.)
24-01-2012