Java Generics: Generic type defined as return type only

Question

I'm looking at some GXT code for GWT and I ran across this use of Generics that I can't find another example of in the Java tutorials. The class name is com.extjs.gxt.ui.client.data.BaseModelData if you want to look at all of the code. Here are the important parts:

private RpcMap map;

public <X> X get(String property) {
  if (allowNestedValues && NestedModelUtil.isNestedProperty(property)) {
    return (X)NestedModelUtil.getNestedValue(this, property);
  }
  return map == null ? null : (X) map.get(property);
}

X is defined nowhere else in the class or anywhere in the hierarchy, and when I hit "go to declaration" in eclipse it just goes to the <X> in the public method signature.

I've tried to call this method with the following two examples to see what happens:

public Date getExpiredate() {
    return  get("expiredate");
}

public String getSubject() {
    return  get("subject");
}

They compile and show no errors or warnings. I would think at the very least I would have to do a cast to get this to work.

Does this mean that Generics allow a magic return value that can be anything and will just blow up at runtime? This seems counter to what generics are supposed to do. Can anyone explain this to me and possibly give me a link to some documentation that explains this a little better? I've went through Sun's 23 page pdf on generics and every example of a return value is defined either at the class level or is in one of the parameters passed in.

Answer 1

The method returns a type of whatever you expect it to be (<X> is defined in the method and is absolutely unbounded).

This is very, very dangerous as no provision is made that the return type actually matches the returned value.

The only advantage this has is that you don't have to cast the return value of such generic lookup methods that can return any type.

I'd say: use such constructs with care, because you lose pretty much all type-safety and gain only that you don't have to write an explicit cast at each call to get().

And yes: this pretty much is black magic that blows up at runtime and breaks the entire idea of what generics should achieve.

Answer 2

The type is declared on the method. That's that "<X>" means. The type is scoped then to just the method and is relevant to a particular call. The reason your test code compiles is that the compiler tries to determine the type and will complain only if it can't. There are cases where you have to be explicit.

For example, the declaration for Collections.emptySet() is

public static final <T> Set<T> emptySet()

In this case, the compiler can guess:

Set<String> s = Collections.emptySet();

But if it can't, you must type:

Collections.<String>emptySet();

Answer 3

I was just trying to figure out the same thing with a GXT class. Specifically I was trying to call a method with the signature of:

class Model {
    public <X> X get(String property) { ... }
}

To call the above method from your code and have it cast X to a String I do the following:

public String myMethod(Data data) {
    Model model = new Model(data);
    return model.<String>get("status");
}

The above code will call the get method and tell it that the type being returned by X should be returned as a String.

In the case where the method is in the same class as you, I've found that I have to call it with a "this.". For example:

this.<String>get("status");

As others have said, this is rather sloppy and dangerous by the GXT team.

Answer 4

BaseModelData raises unchecked warnings when compiled, because it is unsafe. Used like this, your code will throw a ClassCastException at runtime, even though it doesn't have any warnings itself.

public String getExpireDate() {
  return  get("expiredate");
}

Answer 5

Interesting note, from RpcMap (GXT API 1.2)

get's header:

public java.lang.Object get(java.lang.Object key)

Having a generic parameter of <X> in there that's uninstantiated has the same effect, except you don't have to say "Object" all over the place. I agree with the other poster, this is sloppy and a bit dangerous.

Answer 6

Yes, this is dangerous. Normally, you'd protect this code like so:

<X> getProperty(String name, Class<X> clazz) {
   X foo = (X) whatever(name);
   assert clazz.isAssignableFrom(foo);
   return foo;
}

String getString(String name) {
  return getProperty(name, String.class);
}

int getInt(String name) {
  return getProperty(name, Integer.class);
}