exception constraints for explicitly-typed lambdas

Dan Smith daniel.smith at oracle.com
Tue Dec 17 16:38:18 PST 2013


I've resolved the bug.

The problem is not that there are inference variables present, but instead that reduction is too eager to give up when it encounters inference variables.  In your example, it doesn't matter that the parameter type is an inference variable, because we already know the parameter type from the declaration in the lambda expression.

I've updated the reduction rules to be more permissive.

—Dan

On Dec 16, 2013, at 5:18 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> Yes, looks like there's something wrong.  I'll explore further; I've created a bug:
> https://bugs.openjdk.java.net/browse/JDK-8030478
> 
> On Dec 8, 2013, at 8:14 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
> 
>> I may have a bug here, but from all I can see there's s.t.
>> inconsistent as demonstrated by the following example:
>> 
>> class A {}
>> class B extends A { void bar() {} }
>> public class X {
>> public static void main(String[] argv) {
>>   someWithIndex(getList(), (B b) -> b.bar()); // HERE
>> }
>> interface ItemWithIndexVisitor<E> {
>>   public void visit(E item);
>> }
>> public static <G> void someWithIndex(List<G> list, ItemWithIndexVisitor<G> visitor) {}
>> static <I extends A> List<I> getList() { return null; }
>> }
>> 
>> javac accepts this program, but I don't see how:
>> 
>> During invocation type inference for the marked call I get the following:
>> 
>> The set C contains:
>> constraint1: ⟨getList() ⊆throws java.util.List<G#0>⟩
>> constraint2: ⟨(B b) -> b.bar() ⊆throws X.ItemWithIndexVisitor<G#0>⟩
>> 
>> Input variables:
>> constraint1: none
>> constraint2: none
>> 
>> Output variables:
>> constraint1: G#0
>> constraint2: G#0
>> 
>> No input-output dependencies, so both constraints are picked.
>> 
>> The union of input variables is empty, nothing gets resolved nor substituted
>> => constraints remain as given above.
>> 
>> During reduction of constraint2 we fail because of the unsubstituted
>> inference variable G#0.
>> This happens at 18.2.5 bullet 3:
>> one "of the function type's parameter types is not a proper type" -> FALSE
>> 
>> 
>> I must admit that I don't have a good intuition for the terms "input"
>> and "output variables", so I only have a "mechanical" guess as to where
>> the conflict lies; the following don't harmonize:
>> 
>> [a] excluding parameters of explicitly-typed lambdas from input variables
>> ("... the input variables include i) if the lambda expression is implicitly-typed...")
>> 
>> [b] checking parameters of all lambdas in 18.2.5
>> 
>> My guess is that [b] is wrong in some way (completely bogus or should add
>> condition "if lambda expression is implicitly-typed" as done in 18.2.1.1).
>> 
>> Which is it?
>> 
>> best,
>> Stephan
> 



More information about the lambda-spec-observers mailing list