Raw vs Super Type Classes in Java Generics

Question

Given an interface such as,

public interface NumVal<C extends Number>{ 
      /* Put your most sophisticated code ever here! */
} 

is there any actual differences in runtime in using a var like

NumVal myRawVal = (...) vs

NumVal<Number> mySuperVal = (...) ?

I know in compile time the former cause some more warnings. But also after type erasure is supposed to be Number equally according to Oracle, so it is safe anyway, is it not?

Answer 1

You seem to be confused about the erasure of NumVal's declared type variable, C.

public interface NumVal<C extends Number>{ 

The declaration above introduces a new generic type named NumVal. NumVal<Integer> is an example of a parameterization of this type. NumVal is a raw type.

The erasure of C which, by the JLS definition,

The erasure of a type variable (§4.4) is the erasure of its leftmost bound.

is Number, never comes into play in these conceptual definitions.

The fact that NumVal is a raw type has consequences on how you use any reference expressions of that type. When a raw type is involved in an expression, as a method argument, as a method invocation target, etc., the other parts of the expression are also erased. Since they are erased, the compiler cannot guarantee the type safety of the expression and therefore warns you about it.

Potential issues are discussed at length in the canonical:

• What is a raw type and why shouldn't we use it?

Answer 2

If you mistakenly put a Dog in your collection of Cats, and if you have specified type parameters correctly everywhere, then the compiler will raise an error, thereby helping you correct the mistake, and avoid really unnecessary bad surprises at run time.

If you don't specify the type parameters, the compiler cannot help you, and you will likely have some very bad and very unnecessary surprises at room time. If you code perfectly then you'll be fine, you won't need help. But nobody codes perfectly, nobody.

I mean whether Dogs are or not Cats, and provided they impelment Animal, is it Zoo (raw) the same as Zoo if the interface Zoo is defined as Zoo

At run time, the types are erased. Zoo<Animal>, Zoo<T extends Animal>, Zoo<Cat>, etc, are all just Zoo. So yes, you could remove all those <...> type parameters from your code. If your code was perfectly working before, then it will continue to work perfectly. To the program at runtime, it doesn't matter whether you wrote the correct type parameters or not. But if you didn't specify the type parameters, then you might make a mistake.

The type parameters are for your protection, to catch problems as early as possible, at compile time, rather than later. So always use the most appropriate types, and never use raw types.

Answer 3

Although there are very good answers, I saw the cases for which the claim is false thanks to @JB Nizet, and as he did not ventured to adapt it as an answer, I will sum it here with this testcase basttery:

public class NumVal<C extends Number> {
    Integer       nextFibboInt  (int secondLast,int last){ return sum(secondLast,last);};
    C             nextFibboC    (C secondLast,    C last){ return sum(secondLast,last);};
    List<Integer> next2FibbosInt(int secondLast,int last){ return Arrays.asList(sum(secondLast,last), sum(sum(secondLast,last),last));};
    List<C>       next2FibbosC  (C secondLast,    C last){ return Arrays.asList(sum(secondLast,last), sum(sum(secondLast,last),last));};

    @SuppressWarnings({ "rawtypes", "unchecked" })
    public static void main (String[] args){

        Integer  singleGenericSubtype    = new NumVal<Integer>().nextFibboC(1,2);          //This is the exclusive obvious for generics
        Integer  listGenericSubtype      = new NumVal<Integer>().next2FibbosC(1,2).get(0); //This is the exclusive obvious for generics

        Number   singleGenericSuper      = new NumVal<Number> ().nextFibboC(1,2);
        Integer  singleHardcodedTyped    = new NumVal<Integer>().nextFibboInt(1,2);
        Number   listGenericSuper        = new NumVal<Number> ().next2FibbosC(1,2).get(0);
        Integer  listTyped               = new NumVal<Integer>().next2FibbosInt(1,2).get(0);

        Number   singleGenericSuperRaw   = new NumVal().nextFibboC(1,2);            // OK - These are the cases I was assuming as equivalent
        Integer  singleHardcodedTypedRaw = new NumVal().nextFibboInt(1,2);          // OK - These are the cases I was assuming as equivalent
        Number   listGenericSuperRaw     = new NumVal().next2FibbosC(1,2).get(0);   // KO - These are the cases that I did not considerate that fail the hypothesis
        Integer  listHardcodedTypedRaw   = new NumVal().next2FibbosInt(1,2).get(0); // KO - These are the cases that I did not considerate that fail the hypothesis
    }

    private <T extends Number> T sum(T o1, T o2) {
        Number sum = new BigDecimal(o1.toString()).add(new BigDecimal(o2.toString()));
        Object result = -1;
        try { result = o1.getClass().getMethod("valueOf",String.class).invoke(null, sum.toString()); } catch (Exception e){}
        return (T) result;
    }
}

---

• So last 2 cases fail (at compiling), which means erased raw is not interchangable for the super <Number>. Making the class raw seems to erase ANY type of ANY method signatures of the class (Thanks @JB Nizet)
  • The first fail is due to the fact that even if C is correctly erased as Number when alone, List<C> is otherwise erased as List<Object>
  • The second fail is even stranger, and due to the fact that surprisingly my raw class is erasing as well the types of the List<Integer> hardcoded returning methods even when they are not using/related to the class C type in any way