Why does this generic code compile in java 8?

Question

I've stumbled upon a piece of code that has me wondering why it compiles successfully:

public class Main {     public static void main(String[] args) {         String s =  newList(); // why does this line compile?         System.out.println(s);     }      private static <T extends List<Integer>> T newList() {         return (T) new ArrayList<Integer>();     } } 

What is interesting is that if I modify the signature of method newList with <T extends ArrayList<Integer>> it doesn't work anymore.

Update after comments & responses: If I move the generic type from the method to the class the code doesn't compile anymore:

public class SomeClass<T extends List<Integer>> {     public  void main(String[] args) {         String s = newList(); // this doesn't compile anymore         System.out.println(s);     }      private T newList() {         return (T) new ArrayList<Integer>();     } } 

Answer 1

If you declare a type parameter at a method, you are allowing the caller to pick an actual type for it, as long as that actual type will fulfill the constraints. That type doesn’t have to be an actual concrete type, it might be an abstract type, a type variable or an intersection type, in other, more colloquial words, a hypothetical type. So, as said by Mureinik, there could be a type extending String and implementing List. We can’t manually specify an intersection type for the invocation, but we can use a type variable to demonstrate the logic:

public class Main {     public static <X extends String&List<Integer>> void main(String[] args) {         String s = Main.<X>newList();         System.out.println(s);     }      private static <T extends List<Integer>> T newList() {         return (T) new ArrayList<Integer>();     } } 

Of course, newList() can’t fulfill the expectation of returning such a type, but that’s the problem of the definition (or implementation) of this method. You should get an “unchecked” warning when casting ArrayList to T. The only possible correct implementation would be returning null here, which renders the method quite useless.

The point, to repeat the initial statement, is that the caller of a generic method chooses the actual types for the type parameters. In contrast, when you declare a generic class like with

public class SomeClass<T extends List<Integer>> {     public  void main(String[] args) {         String s = newList(); // this doesn't compile anymore         System.out.println(s);     }      private T newList() {         return (T) new ArrayList<Integer>();     } } 

the type parameter is part of the contract of the class, so whoever creates an instance will pick the actual types for that instance. The instance method main is part of that class and has to obey that contract. You can’t pick the T you want; the actual type for T has been set and in Java, you usually can’t even find out what T is.

The key point of generic programming is to write code that works independently of what actual types have been chosen for the type parameters.

But note that you can create another, independent instance with whatever type you like and invoke the method, e.g.

public class SomeClass<T extends List<Integer>> {     public <X extends String&List<Integer>> void main(String[] args) {         String s = new SomeClass<X>().newList();         System.out.println(s);     }      private T newList() {         return (T) new ArrayList<Integer>();     } } 

Here, the creator of the new instance picks the actual types for that instance. As said, that actual type doesn’t need to be a concrete type.

Answer 2

I'm guessing this is because List is an interface. If we ignore the fact that String is final for a second, you could, in theory, have a class that extends String (meaning you could assign it to s) but implements List<Integer> (meaning it could be returned from newList()). Once you change the return type from an interface (T extends List) to a concrete class (T extends ArrayList) the compiler can deduce they aren't assignable from each other, and produces an error.

This, of course, breaks down since String is, in fact, final, and we could expect the compiler to take this into account. IMHO, it's a bug, although I must admit I'm no compiler-expert and there might be a good reason to ignore the final modifier at this point.