What is the point of allowing type witnesses on all method calls?

From the JLS §15.2.12.1:

• If the method invocation includes explicit type arguments, and the member is a generic method, then the number of type arguments is equal to the number of type parameters of the method.

This clause implies that a non-generic method may be potentially applicable to an invocation that supplies explicit type arguments. Indeed, it may turn out to be applicable. In such a case, the type arguments will simply be ignored.

It's followed by justification

This rule stems from issues of compatibility and principles of substitutability. Since interfaces or superclasses may be generified independently of their subtypes, we may override a generic method with a non-generic one. However, the overriding (non-generic) method must be applicable to calls to the generic method, including calls that explicitly pass type arguments. Otherwise the subtype would not be substitutable for its generified supertype.

Along this line of reasoning, let's construct an example. Suppose in Java 1.4, JDK has a class

public class Foo
{
    /** check obj, and return it */
    public Object check(Object obj){ ... }
}

Some user wrote a proprietary class that extends Foo and overrides the check method

public class MyFoo extends Foo
{
    public Object check(Object obj){ ... }
}

When Java 1.5 introduced generics, Foo.check is generified as

    public <T> T check(T obj)

The ambitious backward comparability goal requires that MyFoo still compiles in Java 1.5 without modification; and MyFoo.check[Object->Object] is still an overriding method of Foo.check[T->T].

Now, according to aforementioned justification, since this compiles:

    MyFoo myFoo = new MyFoo();

    ((Foo)myFoo).<String>check("");

This must compile too:

    myFoo.<String>check("");

even though MyFoo.check is not generic.

---

That sounds like a stretch. But even if we buy that argument, the solution is still too broad and overreaching. JLS could've tighten it up so that myFoo.<String,String>check and obj.<Blah>toString() are illegal, because type parameter arity doesn't match. They probably didn't have time to iron it out so they just took a simple route.

It is because of backward- and/or forward-compatibility (at source level).

Imagine something like the introduction of generic parameters for some classes in Swing in JDK 7. It might happen with methods too (even with restrictions). If something turned out to be a bad idea, you can remove them and the source using it would still compile. In my opinion that is the reason why this is allowed, even if it is not used.

The flexibility though is limited. If you introduced type parameters with n types, you cannot later change to m types (in a source compatible way) if m != 0 or m != n.

(I understand this might not answer your question as I am not the designer of Java, this is only my idea/opinion.)

You need the type witness (the type in the diamond) when type inference will not work (see http://docs.oracle.com/javase/tutorial/java/generics/genTypeInference.html)

The example given for this is when daisy-chaining calls like:

processStringList(Collections.emptyList());

where processStringList is defined as:

void processStringList(List<String> stringList) 
{
    // process stringList
}

This will result in an error because it cannot cast a List<Object> to a List<String>. Thus, the witness is required. Albeit, you could do this in multiple steps, but this can be far more convenient.