Disambiguation of functional expressions

If you think Java started its journey through type inference with the var keyword (Java 10), think again. Type inference was introduced with Java 5 and has been increasing in coverage ever since.

With Java 8, the resolution of overloaded methods was restructured to allow for working with type inference. Before the introduction of lambdas and method references, a call to a method was resolved by checking the types of the arguments that were passed to it (the return type wasn't considered).

With Java 8, implicit lambdas and implicit method references couldn't be checked for the types of values that they accepted, leading to restricted compiler capabilities, to rule out ambiguous calls to overloaded methods. However, explicit lambdas and method references could still be checked by their arguments by the compiler. For your information, the lambdas that explicitly specify the types of their parameters are termed explicit lambdas.

Limiting the compiler's ability and relaxing the rules in this way was purposeful. It lowered the cost of type-checking for lambdas and avoided brittleness.

Although it is an interesting feature, the disambiguation of functional expressions is slated as an optional feature in JEP 302, because Oracle needs to assess its impact on the compiler implementation.

Before diving into the proposed solution, let's look at the existing issues, using code examples.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.151.220