This statement is dead on obvious but my problem is: I need to call this method: someMethod (java.lang.Class type, java.lang.Object value)
Scenario 1: (Works) boolean bP = true Boolean bW = new Boolean(bP); someMethod( Boolean.class, bW ); //ok Scenario 2: (Compile error) someMethod( boolean.class, bP ); //error Is there any way to coerce scenario #2 to work? Pho
No, if the method wants an Object, the method'll have an Object. You could shorten it slightly with someMethod( Boolean.class, new Boolean( bP ) ); What's wrong with doing it the first way?
Solution one is the way you coerce it to work. The problem you are describing is the reason for the existence of the wrapper classes that provide object representations of primitive types.
Well if you think about it, boolean.class is a subclass of "Class". and "Class" is a subclass of "Object". So does it mean that the relationships are not transitive ? Pho
Tony. . . naughty, naughty - reading up on microsoft stuff when no one is looking . So are they really primitives and the language disguises that (I think not) or did they make everything a true object??? It is really just the primitives, the special handling of strings, and arrays that prevent java from being a pure object oriented language. How many concessions did C# make???
"JavaRanch, where the deer and the Certified play" - David O'Meara
There's a way to do it better - find it. -Edison. A better tiny ad:
Gift giving made easy with the permaculture playing cards