Java: getClass() of bounded type

Question

I noticed something while I was derping around with generics. In the example below, doStuff1 compiles but doStuff2 doesn't:

public <T extends Foo> void doStuff1(T value) {
    Class<? extends Foo> theClass = value.getClass();
}

public <T extends Foo> void doStuff2(T value) {
    Class<? extends T> theClass = value.getClass();
}

So, I looked up the documentation for Object.getClass() and found this:

The actual result type is Class<? extends |X|> where |X| is the erasure of the static type of the expression on which getClass is called.

This made me a bit curious. Why is getClass() designed this way? I can understand converting types to their raw classes if applicable, but I see no obvious reason why they'd necessarily have to make it also kill off T. Is there a specific reason why it also gets rid of it, or is it just a general "let's just get rid of everything because it's easier; who would ever need it anyway" approach?

Answer 1

If getClass() returns Class<? extends X>, nothing really bad can happen; actually it'll help a lot of use cases.

The only problem is, it is not theoretically correct. if an object is an ArrayList<String>, its class cannot be Class<ArrayList<String>> - there is no such class, there is only a Class<ArrayList>.

This is actually not related to erasure. If one day Java gets full reified types, getClass() should still return Class<? extends |X|>; however there should be a new method, like getType() which can return a more detailed Type<? extends X>. (though, getType may conflict with a lot of existing classes with their own getType methods)

For the timing being, since Class<? extends X> might be useful in a lot of cases, we can design our own method that does that

static <X> Class<? extends X> myGetClass(X x){ ... }

but it's understandable they wouldn't put this kind of hack in standard lib.

Answer 2

Consider the following program:

var a = new ArrayList<String>();
var b = new ArrayList<Integer>();
var aType = a.getClass();        
var bType = b.getClass();        

if (aType == bType) {
  ...
}

If we execute this, aType and bType will contain the same runtime class object (since all instances of a generic type share the same runtime class), and the body of the if statement will execute.

It will also compile just fine. In particular, the declared types of aType and bType are both Class<? extends ArrayList>, and comparing two references of compatible types makes sense to the compiler.

However, if getClass were defined to return Class<? extends T> instead, the compile time types of aType would be Class<? extends ArrayList<String>, and the type of bType would be Class<? extends ArrayList<Integer>>. Since Java defines generics as invariant, these are inconvertible types, and the compiler would thus be required to reject the comparision aType == bType as nonsensical, even though the runtime thinks it true.

Since fixing this would have required a major extension to the java type system, declaring getClass to return the erasure was likely seen as the simpler option, even though it causes counter-intuitive behavior in other cases, such as the one you encountered. And of course, once defined that way, it could no longer be changed without breaking API ...

To work around the workaround, you can use an unchecked cast:

@SuppressWarnings("unchecked")
<T> Class<? extends T> getTypedClassOf(T t) {
   return (Class) t.getClass();
}

Of course, this means that you might need to resort to unchecked casts to get the compiler to understand that class objects of inconvertible types might be identical after all ...

Answer 3

You cannot be sure that value is actually a T, it could also be a subclass of T. getClass() does return the "real" class of value, but you can't be sure that's T, therfore it has to read Class<? extends T>! This has nothing to do with the fact that T is a type parameter.

[Edit] Ok not quite, i didn't realize method2 doesn't compile. I think this is a compiler issue. I get

Type mismatch: cannot convert from Class<capture#1-of ? extends Foo> to Class<? extends T>

I think the compiler only realizes that the T object is a Foo. The compiler should know getClass() returns some Class<? extends T> but only seems to know that it returns some Class<? extends Foo>. Does that mean Foo is the erasure of the static type of T?

Answer 4

Very good question.

The whole problem with java generics is that they didn't exist in old virtual machines. Sun decided to add generic support while existing virtual machine did not support them.

This could be a big problem, because when they release the new Java, old virtual machines would NOT be able to run any code written for the newest version of Java, and they would not have been able to legacy-support old virtual machines.

So, they decided to implement generics in a way that they could also be run in old virtual machines. They decided to ERASE THEM FROM BYTECODE.

So the whole story is about back-support of jvms.

EDIT: But this had maybe nothing to do with the question. See kutschkem's answer!

Also, my guess is that in the second case, the cast is Class<? extends List> to Class<? extends T>. This cast is only possible if List directly extends T (since it is an implicit cast). But its the other way around, T extends List.

I think its the same thing as saying:

String s = "s";
Object o = s;

In the above case, the cast is possible because String extends Object. For the inverse, you would need an explicit cast.

If you add an explicit cast to your program, it compiles:

public <T extends List> void doStuff2(T value) {
   Class<? extends T> theClass = (Class<? extends T>) value.getClass();
}

Answer 5

The guava reflection tools provide some tools to work around this limitation and help you to get the type (so class) of a bounded type.

As said in the first line of this explanation page:

Due to type erasure, you can't pass around generic Class objects at runtime -- you might be able to cast them and pretend they're generic, but they really aren't.

Guava provides TypeToken, which uses reflection-based tricks to allow you to manipulate and query generic types, even at runtime.

The idea is to get (or create) a TypeToken of the bounded type and then you can ask for its type.

I figured that this answer is a bit off topic, because it doesn't answer the question directly (the 'why' part), but it can fix the non compilable method, it can lead to code able to solve the question and to give you the answer to the why part, and will certainly help other people looking for 'Java: - how to -getClass() of bounded type"