intersection type compatibility

Dan Smith daniel.smith at
Fri Dec 6 11:01:11 PST 2013

On Dec 3, 2013, at 8:26 AM, Stephan Herrmann <stephan.herrmann at> wrote:

> Consider this program:
>  import java.util.ArrayList;
>  import java.util.List;
>  public class Compile {
>      public <T, Exp extends List<T>> Exp typedNull() {
>          return null;
>      }
>      public void call() {
>          ArrayList<String> list = typedNull();
>      }
>  }
> May I safely assume that the following error issued by
> javac b117 is a bug, or am I missing a subtle issue
> about intersection types?

Well, it's a spec bug, but one that's already been identified:

What javac is trying to say is that it can't resolve the inference bounds.  And this is consistent with the spec.

When testing for applicability (18.5.1), we get these bounds (trivially):
{ t <: Object, exp <: Object, exp <: List<t> }

And that can be resolved (18.4) to [ t:= Object, exp := List<Object> ].  (Note that exp depends on the resolution of t.)

Then, for invocation type inference (18.5.2), we have an additional constraint:
[ exp -> ArrayList<String> ]

Giving us bounds:
{ t <: Object, exp <: ArrayList<String>, exp <: List<t> }

It would be nice if we could then infer something about t...  But we don't, and so resolution finds t := Object, and then there's no solution for exp.

We're planning to come up with an extra incorporation rule that will handle cases like this.


More information about the lambda-spec-experts mailing list