Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reflection determining return Type as String?

 
Dan Hop
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 20667
65
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic