primitive types not castable as lang.Object

[Pho Tek]

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

[Grant Crofton]

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?

[Anonymous]

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.

[Pho Tek]

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

[Randall Twede]

there is no Class called boolean only one called Boolean

[Cindy Glass]

That's why they are called "primitives". Because they are NOT objects. when you wrapped the boolean primitive with a Boolean object wrapper it worked.

[Tony Alicea]

I know this is of no importance here but... In C#, primitives can be treated as objects transparently.

[Cindy Glass]

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???