GeeCON Prague 2014*
The moose likes Java in General and the fly likes Reflection determining return Type as String? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "Reflection determining return Type as String?" Watch "Reflection determining return Type as String?" New topic
Author

Reflection determining return Type as String?

Dan Hop
Greenhorn

Joined: Aug 02, 2010
Posts: 7
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)



David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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?
Dan Hop
Greenhorn

Joined: Aug 02, 2010
Posts: 7
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
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
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
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.
 
GeeCON Prague 2014
 
subject: Reflection determining return Type as String?