Invoking Java Generic Methods

Question

The shared inherited type of String and Long is Object.

When you run this function as Util.<String>compare( the compiler expects to find two string inputs, and gives an error when it doesn't. However, running it without <String> results in the use of the closest shared inherited type - in this case, Object.

Thus, when compare accepts t1 and t2, they have been cast as Object, and the code runs fine.

To get the actual type at runtime you use the same technique that you would use with any other object: The getClass() which is inherited from the Object class.

The answer seems to go beyond @Telthien and @newacct' answers. I was curious to "see" for myself the difference between:

System.out.println(Util.<String>compare("a", "b"));

with explicity typing, and:

System.out.println(Util.compare(new String(""), new Long(1)));

with implicit typing.

I performed several experiments, using variations on these two previous lines. These experiments show that, short of using the anonymous/local class trick, the compiler does check the types during compilation but the generated bytecodes only refer to Object, even in the case of the first line.

The following piece of code shows that typecasts can be performed safely all the way to Object even in the case of the explicity type argument <String>.

public final class Example44 {
    public static void main(final String[] args) {
        System.out.println(new Util44<String>().compare("a", "b"));
        System.out.println(new Util44().compare(new String(""), new Long(1)));
    }
}

final class Util44<T> {
    private T aT;
    public boolean compare(T t1, T t2) {
        System.out.println(this.aT);
        // I was expecting the second and third assignments to fail
        // with the first invocation because T is explicitly a String
        // and then to work with the second invocation because I use
        // a raw type and the compiler must infer a common type for T.
        // Actually, all these assignments succeed with both invocation. 
        this.aT = (T) new String("z");
        this.aT = (T) new Long(0);
        this.aT = (T) new Object();
        return t1.equals(t2);
    }
}

The bytecodes of the main method look like:

  // Method descriptor #15 ([Ljava/lang/String;)V
  // Stack: 7, Locals: 1
  public static void main(java.lang.String[] args);
     0  getstatic java.lang.System.out : java.io.PrintStream [16]
     3  new ca.polymtl.ptidej.generics.java.Util44 [22]
     6  dup
     7  invokespecial ca.polymtl.ptidej.generics.java.Util44() [24]
    10  ldc <String "a"> [25]
    12  ldc <String "b"> [27]
    14  invokevirtual ca.polymtl.ptidej.generics.java.Util44.compare(java.lang.Object, java.lang.Object) : boolean [29]
    17  invokevirtual java.io.PrintStream.println(boolean) : void [33]
    20  getstatic java.lang.System.out : java.io.PrintStream [16]
    23  new ca.polymtl.ptidej.generics.java.Util44 [22]
    26  dup
    27  invokespecial ca.polymtl.ptidej.generics.java.Util44() [24]
    30  new java.lang.String [39]
    33  dup
    34  ldc <String ""> [41]
    36  invokespecial java.lang.String(java.lang.String) [43]
    39  new java.lang.Long [46]
    42  dup
    43  lconst_1
    44  invokespecial java.lang.Long(long) [48]
    47  invokevirtual ca.polymtl.ptidej.generics.java.Util44.compare(java.lang.Object, java.lang.Object) : boolean [29]
    50  invokevirtual java.io.PrintStream.println(boolean) : void [33]
    53  return
      Line numbers:
        [pc: 0, line: 24]
        [pc: 20, line: 25]
        [pc: 53, line: 26]
      Local variable table:
        [pc: 0, pc: 54] local: args index: 0 type: java.lang.String[]

It actually makes sense that all the calls are always to methods with Object as formal parameter types, as explained in another question/answer. To conlude, the compiler always uses Object for the generated bytecodes, not matter if there is an explicity type argument (first line) or an implicit type argument but that the objects could have a common superclass different from Object.

Yes, Object is a choice for T that will allow it to compile. Conceptually, the compiler infers a type for T. What it particularly infers doesn't matter -- as long as it can infer that some type will work for T, then it compiles. It doesn't matter what that inferred type is, since it has no effect on the compiled code.