I found a 'unusual' generic syntax such as:
Arrays.<String>asList(...);
Collections.<String>emptyList();
Obviously, the results of the methods are generic. Is such syntax for type checking? An Object array cannot be an argument to Arrays.<String>asList(...).
<typearg>methodname is the syntax for explicitly specifying the type argument for a generic method
When you use a generic class, you usually have to specify the type argument (e.g. String):
ArrayList<String> list = new ArrayList<String>();
With a generic method, you don't usually pass a type argument:
public static <T> void foo(T param) { }
...
String s = ...;
MyClass.foo(s);
You'll notice no where did we did the code explicitly specify we want the String version of foo, i.e. there was no explicit type argument <String> specified like we saw when using a generic class (List<String>).
The compiler is doing some compiler magic to infer the generic type argument based on context. This is a great thing and very powerful.
However, occassionally the compiler can't infer the type arguments automatically:
public static <T> void bar() { T myLocalVar = ...; ... }
MyClass.bar();
What concrete version of bar are we trying to invoke, i.e. what is the type argument for this call? Dunno? Well, the compiler doesn't either. We have to explicitly state the type argument, just like we normally do when using a generic class:
MyClass.<String>bar();
Also see:
Aside: it may be worth mentioning that the Java 7 will be adding the so-called diamond operator to allow us to have the compiler to infer the type arguments when using generic classes now too:
ArrayList<String> list = new ArrayList<String>();
becomes
ArrayList<String> list = new ArrayList<>();
What is the point of the diamond operator (<>) in Java 7?
This is how you explicitly specify the type parameter to a generic method. In most cases, the compiler can infer it, but sometimes it needs to be explicitly stated.
The answers above pretty much address your question, but if you want a specific example of a case where Java's generic type inference fails and explicitly stating it in this way saves the day, consider the following class definitions:
public class A { }
public class B extends A { }
public class C extends A { }
Then the following code works just fine (i.e., Java's type inference succeeds):
List<Class<? extends A>> list = ImmutableList.of(B.class, C.class);
But for the following, it fails to compile:
List<Class<? extends A>> list = ImmutableList.of(B.class);
That's right; strangely enough, by removing a parameter, we confuse the type inference system, since the 'nearest common descendant' of B.class and C.class is A.class, but for B.class by itself, it's just B.class, which (by lack of covariance in Java's generics) does not match List<Class<? extends A>>. In this case, you have no choice but to use:
List<Class<? extends A>> list = ImmutableList.<Class<? extends A>>of(B.class);
Since B does indeed extend A, this compiles (and runs) just fine.
I hope this demonstration emphasizes the usefulness of the operator.
In addition, after Java 7 compiler support type inference. Consider the following class definitions:
public class A { }
public class B extends A { }
public class C extends A { }
All the following cases are working:
List<Class<? extends A>> list0 = Arrays.asList(B.class, C.class);
List<Class<? extends A>> list1 = Arrays.asList(B.class);
List<A> list2 = Arrays.asList(new B());
List<A> list3 = Arrays.asList(new B(), new C());
List<? extends A> list4 = Arrays.asList(new B(), new C());
List<? extends A> list5 = Arrays.asList(new B());
