Sorry for not responding earlier — got a little distracted.

The reason for not propagating downward, is that the fundamental nature of generics is that you really do not have fully parameterized types of the superclasses of (for example) ExampleMap<Integer,String>. Creating a fully parameterized subtype is no different at all from “regular” subclassing — it does not suddenly create a whole, parallel class hierarchy. That is, Java does not end up with Example<T>, Example<Integer>, Example<String> and all sorts of other, parallel types just to support subtypes. Java introduces fully parameterized types only when the type hierarchy actually stops being generic.

Note that this is fundamentally different from genericity in C++ (for example) where the compiler really just performs macro expansion and actually does introduce parallel hierarchies. Java, by contrast, uses “real” inheritance to move from generic to parameterized types. So, in effect, the reason for “no propagation” is the same as the reason that subclasses in Java don’t have copies of their parent’s methods but really do delegate to their parents in case of inheritance: because Java uses real inheritance and not “simulated inheritance.”

With a type hierarchy that has a “concrete” parameter at the top level (such as ExampleSerializable<String>), why not propagate that “concrete” parameter down the type reflection hierarchy? So that instead of reflecting to retrieve supertype Example<T>, reflection would return supertype Example<String>?

It seems to me being able to discover the parameter at generic levels of the type hierarchy would be very handy — such as in cases where you need to find out the parameter type for generic class Example<T>, but don’t know anything about subclass(es).

Consider an example:

public class ExampleIntegerToString extends ExampleMap<Integer,String>
public class ExampleMap<X,Y> extends Example<Y>
public class Example<T>

In this example, if Example<T> wanted to reflect on the “concrete” type of <T> (in this case, <String>), it would not be able to do so safely, even if it did try to reflect on the subclass ExampleMap<Integer,String>.

Any idea why this is not feasible? I’m sure there was some reason inside the JVM to make it impractical…

Or perhaps I have completely misunderstood the nature of the problem.

Thanks again Ben! Cheers,

Johann

Your clear explanation is what I was clumsily trying to get across in my comment about “sub-typing”.

With a type hierarchy that has a “concrete” parameter at the top level (such as ExampleSerializable), why not propagate that “concrete” parameter down the type reflection hierarchy? So that instead of reflecting to retrieve supertype Example, reflection would return supertype Example?

It seems to me being able to discover the parameter at generic levels of the type hierarchy would be very handy — such as in cases where you need to find out the parameter type for generic class Example, but don’t know anything about subclass(es).

Consider an example:

public class ExampleIntegerToString extends ExampleMap
public class ExampleMap extends Example
public class Example

In this example, if Example wanted to reflect on the “concrete” type of (in this case, ), it would not be able to do so safely, even if it did try to reflect on the subclass ExampleMap.

Any idea why this is not feasible? I’m sure there was some reason inside the JVM to make it impractical…

Or perhaps I have completely misunderstood the nature of the problem.

Thanks again Ben! Cheers,

Johann

First of all, thanks for the compliment.

Your post was partially obliterated by WordPress’ HTML processor, so I hope I have correctly interpreted your comment to be about the following situation:


StringExample extends ExampleSerializable<String>
ExampleSerializable<T> extends Example<T>
Example<T>


No, they didn’t limit the depth of subtyping to 1. The problem is more fundamental than that: the JVM never creates a ParameterizedType for Example<String>. And the reason is that in your type hierarchy, the first fully parameterized, non-generic type is ExampleSerializable<String> — up to that point the entire hierarchy is generic and there is no concept of a non-generic form of the Example type.

You can see this by running the following program:


import java.io.Serializable;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

class StringExample extends ExampleSerializable<String> {
    public static void main(String[] args) {
        new StringExample().reportType();
    }
}


which prints the two lines


ExampleSerializable<java.lang.String>
Example<T>


As you can see, the parameterized supertype of ExampleSerializable<java.lang.String> is the generic, non-instantiated type Example<T>. Which brings us to the reason for the error you are getting: when you request the first type parameter of Example<T>, you don’t get a class, but a type variable (which is not a supertype of java.lang.Class).

Hope that helps (or at least, doesn’t disappoint too badly).

Best regards,

Ben.

Interesting: if we derive from Example a more specific class ExampleSerializable, and then try to determine the parameterized type of Example, it seems to be impossible. (Or “non-reifiable” I guess.)

To test, take the final example code, and after line 7 add:

pType = (ParameterizedType) ( (Class) pType.getRawType () ).getGenericSuperclass ();

That will get the superclass of ExampleSerializable (which is Example) as a parameterized type, so that we can reflect on the parameter .

Then change StringExample to derive from ExampleSerializable (rather than directly from Example).

public class StringExample extends ExampleSerializable {}

Then create a new class “ExampleSerializable”:

import java.io.Serializable;

public class ExampleSerializable
extends Example
{
}

So now we have a hierarchy of 3 derived classes:

StringExample extends ExampleSerializable
ExampleSerializable extends Example
Example

The reportType() code chokes at runtime trying to cast the first “actual type argument” to a Class:

Exception in thread “main” java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to java.lang.Class
at Example.reportType(Example.java:14)
at StringExample.main(StringExample.java:4)

So far in my explorations I have not found anyway to determine what the type of Example is. The only remedy is to remove the “interim” class ExampleSerializable.

So I guess rather than create more reflective types at runtime, the powers-that-be decided to limit the depth of sub-typing to 1?

Seems somewhat arbitrary, considering the Type objects are only really instantiated when the reflection user actually asks for them… They’re not “real” types inside the JVM.

Or am I all muddled?

I don’t suppose there are any workarounds for the “2 levels of sub-typing” case?

Thanks again Ben & cheers,

Johann Tienhaara