intersection type compatibility

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


On Dec 3, 2013, at 8:26 AM, Stephan Herrmann <stephan.herrmann at berlin.de> 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:
https://bugs.openjdk.java.net/browse/JDK-8028813

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.

—Dan


More information about the lambda-spec-experts mailing list