Question

Example A

Study the following snippet:

public class ExampleA {
   static class Pair<F,S> { }

   static <F,S> Pair<F,S> anyPair() { return null; }

   static <F,S> void process(Pair<F,S> p1, Pair<F,S> p2) { return; }

   public static void main(String[] args) {
      Pair<String,Integer> p = anyPair();

      process(p, anyPair()); // doesn't compile
   }
}

Can someone explain why type inference works for the assignment to local variable p but not for the second actual parameter to process?

---

Example B

This is perhaps simpler to understand:

public class ExampleB {     
   public static <E> void process(Set<E> s1, Set<E> s2) { return; }

   public static void main(String[] args) {
      process(new HashSet<String>(), Collections.emptySet()); // doesn't compile
   }
}

Same question: why doesn’t it compile?

I’d hope that Collections.emptySet() would just work for ANY parameterized Set type.

Answer 1

Your second call to anyPair() does not have any way to determine it’s types and so it defaults to <Object, Object>.

The compiler is breaking process(p, anyPair()); into it’s pieces and processing each individually. When it does this, it needs to process the arguments first to determine their types, which can then be used when processing process.

When it goes to process anyPair() there is no type information available for that piece, because it does not know that it is part of process at that point. It defaults to <Object, Object>, which then causes a type mismatch when looking at process.

The same thing happens with your second example. Collections.emptySet() needs to be processed by itself, but has no way of determining the Types needed.

There are 2 ways to solve this:

The first is to give the compiler the information it needs for type inference the same way you did with the first call to anyPair(), by storing it in a temporary variable with the correct type.

The second (thanks to @BalusC) is to use ExampleA.<String, Integer>anyPair(). This syntax explicitly sets the types needed without having to look beyond the invocation.