exception constraints for explicitly-typed lambdas

Stephan Herrmann stephan.herrmann at berlin.de
Sun Dec 8 07:14:52 PST 2013

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

Which is it?


More information about the lambda-spec-experts mailing list