Why generics work in that strange way?

[Lukas Stephienn]

Hi,

I spotted some strange thing in generics.

This code works fine, method automatically returns what it should:

public static <T> ArrayList<T> newArrayList() {
return new ArrayList<T>();
}
public static void main(String[] args) {
List<String> strings = newArrayList();
}

Strange is that following code does not compile:

public static <T> ArrayList<T> newArrayList() {
return new ArrayList<T>();
}

public static void takeList(List<String> l) {
}

public static void main(String[] args) {
takeList( newArrayList());
}

takeList method does not accept argument returned by newArrayList().

So, the question is why this generic method in assignment works fine, while putting it as a method argument fails?
Thanks in advance.
[ October 31, 2008: Message edited by: Lukas Stephienn ]

[Campbell Ritchie]

Because you are not supplying any information to the compiler about what <T> to use.

[Lukas Stephienn]

But in both cases in wrote that I want to have List<String>.
On left side of assignment operator in first case.
In argument in second case.

[Jeanne Boyarsky]

public static <T> ArrayList<T> newArrayList() {
  return new ArrayList<T>();
}

Looking at this in isolation, how can you tell that a String is desired? There's nothing a caller can pass to indicate this fact. And the compiler can't go by what you are storing the result in.

[Charles Lyons]

You would really want to do this (if indeed you would really want to do this):

public static <T> ArrayList<T> newArrayList(Class<T> type) {
  return new ArrayList<T>();
}

Then invoke with:

newArrayList(String.class);

You're now telling the compiler at compile-time what type T is (String in fact). Good for demonstration purposes, pointless in production.
[ October 31, 2008: Message edited by: Charles Lyons ]

[Rob Spoor]

Or just use the intermediate variable:

List<String> list = newArrayList();
takeList(list);

[Campbell Ritchie]

But the last 3 words of Charles Lyon's post said it all.

[Garrett Rowe]

Originally posted by Charles Lyons:
You would really want to do this (if indeed you would really want to do this):

public static <T> ArrayList<T> newArrayList(Class<T> type) {
  return new ArrayList<T>();
}

Then invoke with:

newArrayList(String.class);

Why would this be more desirable than the OP's original code?
[ October 31, 2008: Message edited by: Garrett Rowe ]

[Charles Lyons]

Why would this be more desirable than the OP's original code?

Perhaps because the OP explictly wanted to do:

takeList(newArrayList(String.class));

in the second example, without an intervening local variable? As an exercise in using generics it's good as well: there are cases where passing a Class as an argument to determine the type of a generic method is useful. Though as we ascertained, neither are better than:

List<String> strings = new ArrayList<String>();

[Marcin Mogiela]

"Effective Java second edition" by Joshua Bloch writes that one of the advantages of static factory methods is that they reduce the verbosity of creating parametrized type instances.

Such as:

public static <K, V> HashMap<K, V> getInstance() {
    return new HashMap<K, V>();
}

and a wordy declaration:

Map<String, List<String>> m = new HashMap<String, List<String>>();

could be replaced by more succinct alternative. Example:

Map<String, List<String>> m = HashMap.getInstance();

I think the question is not the usefulness of such practices, but why it is impossible to use HashMap.getInstance() method invocation as an argument to a method. Such method does not really exist but suppose it does. The example comes from the book.
[ November 03, 2008: Message edited by: Marcin Mogiela ]