An early believer in the ability of Java to deliver "enterprise-grade" software, Andrew Phillips quickly focused on the development of high-throughput, resilient and scalable J2EE applications. Specializing in concurrency and high performance development, Andrew gained substantial experience of the intricacies, complexity and challenges of enterprise application environments while working for a succession of multinationals. Continuously focused on effectively integrating promising new developments in the Java space into corporate software development, Andrew joined XebiaLabs in March 2009, where he is a member of the development team of their deployment automation product Deployit. Amongst others, he also contributes to Multiverse, an open-source Java STM implementation, and jclouds, a leading Java cloud library. Andrew is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

“When a class with type parameters is not a parameterized class” – a Java Generics Puzzler

04.22.2010
| 12211 views |
  • submit to reddit

While recently fiddling with some more runtime generic type extraction for Deployit, I was caught out by some unexpected behaviour by the reflection API. A check of the Javadocs quickly revealed that I had once again been too hasty in relying on "common sense". Still, the case seems sufficiently unintuitive to merit discussion.

In this case, the issue centres on the interplay between Class.getTypeParameters and ParameterizedType. The gist of the code looks something like:

 
interface Spying {}

// small class hierarchy
class Person {}
class Professional<P> extends Person {}

class Agent extends Professional<Spying> {}
class Assassin extends Professional {}
class Bystander extends Person {}

...

Person jbond = new Agent();
System.out.println("Generic superclass type argument: " + tryGetSuperclassGenericTypeParam(jbond));

Person joepublic = new Bystander();
System.out.println("Generic superclass type argument: " + tryGetSuperclassGenericTypeParam(joepublic));

Person oddjob = new Assassin();
System.out.println("Generic superclass type argument: " + tryGetSuperclassGenericTypeParam(oddjob));

...

Type tryGetSuperclassGenericTypeParam(Object obj) {
Class<?> clazz = obj.getClass();
Class<?> superclass = clazz.getSuperclass();

// Elvis would be preferred, but for the sake of clarity...
if (superclass.getTypeParameters().length > 0) {
return ((ParameterizedType) clazz.getGenericSuperclass()).getActualTypeArguments()[0];
} else {
return null;
}
}


 

So...what happens?

tryGetSuperclassGenericTypeParam is where the action happens. It seems fairly straightforward: see if the object's superclass is generic (i.e. takes type parameters) and, if so, cast its Type representation to ParameterizedType to extract the actual value for the type parameter. If the superclass is not generic, simply return null.

When this code is run, the first two invocations of tryGetSuperclassGenericTypeParam result in the expected:

Generic superclass type argument: interface Spying
Generic superclass type argument: null

What about the third one? Well, given the fact that we've omitted to specify a generic type parameter for Professional we might assume1 that we'd also get null. The actual output, however, is:

Exception in thread "main" java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
at tryGetSuperclassGenericTypeParam(...)

Huh?

In order to figure out what's going on here, let's have a look at the Javadoc for Class.getTypeParameters:

Returns an array of TypeVariable objects that represent the type variables declared by the generic declaration represented by this GenericDeclaration object, in declaration order. Returns an array of length 0 if the underlying generic declaration declares no type variables.

In other words, this is returning class-level information about the declaration of, in our case, the Professional class, which of course does have a type parameter.
However, if we look at Class.getGenericSuperclass2, which we invoke next, we find that it:

Returns the Type representing the direct superclass of the entity [...] represented by this Class.

If the superclass is a parameterized type, the Type object returned must accurately reflect the actual type parameters used in the source code.

Here, the information returned is specific to the actual declaration of the class, which may (or may not, as in our case) specify type paramaters for its superclass.

And therein lies the problem: Professional.class.getTypeArguments looks at the declaration of the Professional class, discovering a type argument, whereas Assassin.class.getGenericSuperclass looks at the occurrence of Professional in the declaration of Assassin and discovers no type parameters. Hence, it returns a Class rather than a ParameterizedType and blows up our code.

Ergo

To cut a long story short: if an object's superclass has type arguments as determined by Class.getTypeArguments that does not mean that object.getClass().getGenericSuperclass() will be a ParameterizedType.

Footnotes
  1. Read "I assumed" ;-)
  2. It's a pity that Class.getGenericSignature, which determines the "generic or not" behaviour of Class.getGenericSuperclass, is private, native and undocumented.
  • Share/Bookmark

 

From http://blog.xebia.com/2010/04/22/when-a-class-with-type-parameters-is-not-a-parameterized-class-a-java-generics-puzzler/

Published at DZone with permission of Andrew Phillips, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: