Reflection determining return Type as String?

[Dan Hop]

This feels like a dumb question..but..How can determine the Object type being returned from a method?

I have tried: where when I call this method with a class and a function that returns and Integer..
it never falls into the Integer section?

what mechanism am I supposed to use to determine the type of t? (In the debugger the value fields shows up as: Class<T> (java.lang.Integer)

 
 private Object getType(String a, String method) throws Exception {
        Class c = Class.forName(a);
        Method m = c.getMethod(method, null);
        Type t = m.getReturnType();
        
        if (t.equals(Integer.TYPE)) {
            System.out.println("1");
        }
        else if (t.equals(Long.TYPE)){
            System.out.println("2");
        }
        System.out.println("3");
        return null;
    }

[David Newton]

I can't reproduce what you're seeing; it works fine for me. Maybe if you posted the class/method combo you're trying it with?

package reflection;

import java.lang.reflect.Method;
import java.lang.reflect.Type;

public class RetType {

    public int foo() { return 0; }

    public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException {
        Class fooClass = Class.forName("reflection.RetType");
        Method m = fooClass.getMethod("foo", null);
        boolean returnsInteger = ((Type) m.getReturnType()).equals(Integer.TYPE);
        System.out.printf("%s.%s returns Integer? %s%n", fooClass.getCanonicalName(), m.toString(), returnsInteger);
    }
}

// Output:
reflection.RetType.public int reflection.RetType.foo() returns Integer? true

[Dan Hop]

ok well thats weird, I just re-did the same logic in a test app, and its working just like you saw..will have to retry it when I can get back to my original code.

ok well then one follow up..

lets say the return type is of Type String?

how would I test for that..String does not have a 'TYPE' field?


humbled Java Dev...
thanks Dan

[Ernest Friedman-Hill]

David only indirectly pointed out the problem with your assumptions, so I'll make it explicit: Integer.TYPE is actually a special pseudo-class representing "int", while Integer.class would be the class representing java.lang.Integer. They're different types, obviously. Every class has a fake ".class" member like this.

[David Newton]

Yeah, I should have been more clear; I was going to include a String example in my original response but didn't. Thanks for the follow up.

[Mike Simmons]

Ernest Friedman-Hill wrote:David only indirectly pointed out the problem with your assumptions, so I'll make it explicit: Integer.TYPE is actually a special pseudo-class representing "int",

which can also be referenced as int.class

For reference:

Boolean.TYPE == boolean.class
Byte.TYPE == byte.class
Short.TYPE == short.class
Character.TYPE == char.class
Integer.TYPE == int.class
Long.TYPE == long.class
Float.TYPE == float.class
Double.TYPE == double.class
Void.TYPE == void.class

Personally I've never had a need for the TYPE field, as I just use the corresponding .class notation instead. But I suppose it might be useful if you've got a Class object representing a wrapper class, and need to find the corresponding primitive type.

Ernest Friedman-Hill wrote:while Integer.class would be the class representing java.lang.Integer. They're different types, obviously.

though very similar and easily confused

Ernest Friedman-Hill wrote:Every class has a fake ".class" member like this.

Every class does, and every interface, and every primitive. And even a void return type is represented by Void.class and void.class. It's very confusing - the Class class has a very misleading name, since it really represents more than just classes. And for primitive types there are two closely-related Class objects - one for the primitive itself, and one for the wrapper.

I think calling this "fake" is also misleading. Both int.class and Integer.class represent real Class objects in the JVM. But there is no member variable called "class". I guess that's what EFH meant by "fake .class member". I just wanted to point out that it's not a member, but it is real.

Dan Hop wrote:lets say the return type is of Type String?

how would I test for that..String does not have a 'TYPE' field?

Just use String.class. For most classes this is all you need, the .class object. Primitives are more complex, because there's a .class for the primitive itself (like int.class) and a .class for the wrapper class for the primitive (like Integer.class). And you need to pay attention to which is which. But for other classes like String, there are no corresponding primitive classes, and the regular Class object (like String.class) is all you need.

[Rob Spoor]

Mike Simmons wrote:And even a void return type is represented by Void.class and void.class.

Surely you mean Void.TYPE and void.class. Void.class is definitely different.

[Mike Simmons]

No, I was intentionally referring to the fact that there are two different Class objects, void.class and Void.class, which represent the concept of a void return type. The one returned by getReturnType() is void.class, but Void.class does exist too, so I mentioned it. I can't think of a good use for Void.class, but I have seen Void used as a type parameter - Callable<Void> for example.