Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (546)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Class:isAssignableFrom doesn't autobox primitives.  (Read 2893 times)
0 Members and 1 Guest are viewing this topic.
Offline JonathanC

Senior Newbie





« Posted 2008-11-08 21:34:57 »

1  
2  
3  
Object[] a = new Object[] {1.0f};
System.out.println(float.class.isAssignableFrom(a[0].getClass())); //returns false
System.out.println(Float.class.isAssignableFrom(a[0].getClass())); //returns true


Is there an elegant solution to this? I'm using this in tandem with Method:invoke, and the hackish solution right now is to change the parameters in the called function to their non-primitive counterparts, but that's not really acceptable in the long run...
Online Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2008-11-08 22:36:23 »

Just fill a Map<Class, Class> with primitive classes TO box classes


map.put(int.class, Integer.class);
map.put(float.class, Float.class);

Class<?> pass = ....;
Class<?> box = map.get(pass);
if(box != null)
   pass = box;


This way you replace your primitive types and keep all others.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Online Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2008-11-08 23:29:13 »

It's also probably much faster to just iterate over an array...

1  
2  
3  
4  
5  
6  
7  
8  
Class[] from = new Class[]{byte.class,short.class,......}
Class[] to = new Class[]{Byte.class,Short.class,......}


for(int i=0; i<9; i++)
   if(c == from[i])
       return to[i];
return c;

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #3 - Posted 2008-11-09 00:41:52 »

1  
2  
3  
Object[] a = new Object[] {1.0f};
System.out.println(float.class.isAssignableFrom(a[0].getClass())); //returns false
System.out.println(Float.class.isAssignableFrom(a[0].getClass())); //returns true


Is there an elegant solution to this? I'm using this in tandem with Method:invoke, and the hackish solution right now is to change the parameters in the called function to their non-primitive counterparts, but that's not really acceptable in the long run...

Perhaps i'm missing something but... is this Object array 'a' being used as the 'args' parameter to your call to Method:invoke(...)?

If so, the implementation automatically unwraps the Object types to their primitive counterparts, so you won't have to do a thing?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline JonathanC

Senior Newbie





« Reply #4 - Posted 2008-11-09 06:46:30 »

Perhaps i'm missing something but... is this Object array 'a' being used as the 'args' parameter to your call to Method:invoke(...)?

If so, the implementation automatically unwraps the Object types to their primitive counterparts, so you won't have to do a thing?

Well, it unwraps the Object types to their primitive counterparts, but according to Sun's reflection article, isAssignableFrom returns false if either class involved is a primitive. They don't hint at any workaround though.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #5 - Posted 2008-11-09 20:38:57 »

This got me curious as to how exactly Method:invoke(...) performs the automatic unwrapping of the 'args' parameters to their primitive types - whether they do what Riven suggested, or something more 'magic'.

I wish now that I hadn't looked, as it was:
a) a waste of time
b) shocking.

Apparently Method:invoke(...) falls through to the MethodAccessor interface; a concrete implementation of which is obtained from a MethodAccessorGenerator.
The MethodAccessorGenerator.generate(...) is the shocking part - it contains code to generate (at runtime) the bytecode representation of a class file (a subclass of 'MagicAccessorImpl' that implements the MethodAccessor interface.), that it subsequently defines, instanciates & returns.

Ergo there is no source code to read, or class file in the rt.jar to decompile, to see exactly how Method:invoke(...) does it's magic persecutioncomplex

I suppose if you were *realy* interested you could try to hack the jre to store the runtime generated class definition somewhere... but I've a feeling the reason they don't create the class file definition until runtime, is because this stuff is so low level it probably has to account for the code mangling that jit & hotspot are doing.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Online Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #6 - Posted 2008-11-09 21:37:08 »

Darn...

I think your found the core of the overhead of reflection.

Are they caching the result for the Class[] that can be derived from an Object[] or are they simply generating bytecode for every invoke?

(Sorry, I'm too lazy to investigate, and you probably know it already)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #7 - Posted 2008-11-09 22:05:40 »

Darn...

I think your found the core of the overhead of reflection.

Are they caching the result for the Class[] that can be derived from an Object[] or are they simply generating bytecode for every invoke?

(Sorry, I'm too lazy to investigate, and you probably know it already)

The MethodAccessor is generated only once (the first time the method is invoked) for a Method, so no that won't be the reason reflection is slow. (so long as you keep hold of the the Method instance for whatever it is you are invoking)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Mr_Light

Senior Member




shiny.


« Reply #8 - Posted 2008-11-10 05:22:26 »

Sounds like its working as expected.

Your not passing a primitive at all nor a literal just a simple Class object which possibly belongs to a primitive.

Primitive and wrapper classes themselves get auto-boxed not their Runtime class objects.

1  
Object[] a = new Object[] {1.0f};

auto-boxing already happens here the float is auto-boxed in a Float and then is put in the array.

Moreover even if the voodoo-magic your expecting was there, getClass() can't be called on a float.

Also I thought auto-boxing was only there as syntax sugar not for weird constructs.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (22 views)
2014-08-19 09:29:53

Tekkerue (22 views)
2014-08-16 06:45:27

Tekkerue (21 views)
2014-08-16 06:22:17

Tekkerue (12 views)
2014-08-16 06:20:21

Tekkerue (19 views)
2014-08-16 06:12:11

Rayexar (57 views)
2014-08-11 02:49:23

BurntPizza (37 views)
2014-08-09 21:09:32

BurntPizza (29 views)
2014-08-08 02:01:56

Norakomi (36 views)
2014-08-06 19:49:38

BurntPizza (66 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!