How to Tell Which Class an Object Is

[kvnsmnsn]

Below I'm including the source code for a Java application that con-
tains an interface <If> and two classes that implement it, <Abc> and
<Def>. <Rndm.open> flips a coin and returns an object of class <Abc>
half the time and an object of class <Def> the other half of the time.
Then in my <main> method I call <Rndm.open> and assign its value to
object <xyz>. How can I tell which class <xyz> is, <Abc> or <Def>? I
wrote the code below to help me tell, but when I try to compile it I
get the error message:

Gc.java:36: cannot find symbol
symbol : variable Abc
location: class Gc
if (xyz.getClass() == Abc)
^
1 error

Can anyone see what I'm doing wrong? Any feedback on this would be
greatly appreciated. My code follows:

import java.util.Random;

interface If
{
}

class Abc implements If
{
}

class Def implements If
{
}

class Rndm
{
static If open ()
{
Random rndm = new Random();

if (rndm.nextInt( 2) == 0)
{ return new Abc();
}
else
{ return new Def();
}
}
}

public class Gc
{
public static void main ( String[] arguments)
{
If xyz = Rndm.open();

if (xyz.getClass() == Abc)
{ System.out.println( "Method <open> generated an <Abc>.");
}
else
{ System.out.println( "Method <open> generated an <Def>.");
}
}
}

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[Chiron Paixos]

Below I'm including the source code for a Java application that con-
tains an interface <If> and two classes that implement it, <Abc> and
<Def>. <Rndm.open> flips a coin and returns an object of class <Abc>
half the time and an object of class <Def> the other half of the time.
Then in my <main> method I call <Rndm.open> and assign its value to
object <xyz>. How can I tell which class <xyz> is, <Abc> or <Def>? I
wrote the code below to help me tell, but when I try to compile it I
get the error message:

Gc.java:36: cannot find symbol
symbol : variable Abc
location: class Gc
if (xyz.getClass() == Abc)
^
1 error

If you insist on using getClass() look at the following example which
uses a Class object to print the Class name of an object:



void printClassName(Object obj) {
System.out.println("The class of " + obj +
" is " + obj.getClass().getName());
}

Maybe you should consider using instanceOf

 

[Dave Glasser]

(e-mail address removed) wrote on 29 Sep 2005 12:06:30 -0700 in
comp.lang.java.programmer:

Below I'm including the source code for a Java application that con-
tains an interface <If> and two classes that implement it, <Abc> and
<Def>. <Rndm.open> flips a coin and returns an object of class <Abc>
half the time and an object of class <Def> the other half of the time.
Then in my <main> method I call <Rndm.open> and assign its value to
object <xyz>. How can I tell which class <xyz> is, <Abc> or <Def>? I
wrote the code below to help me tell, but when I try to compile it I
get the error message:

Gc.java:36: cannot find symbol
symbol : variable Abc
location: class Gc
if (xyz.getClass() == Abc)

Use the class literal for Abc, which is Abc.class:

if(xyz.getClass().equals(Abc.class)) {
...

Using the == operator would probably also work:

if(xyz.getClass() == Abc.class) {
....

but I think using .equals() is safer.


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

 

[kvnsmnsn]

Chiron Paixos posted:

=If you insist on using getClass() look at the following example which
=uses a Class object to print the Class name of an object:
=
= void printClassName(Object obj) {
= System.out.println("The class of " + obj +
= " is " + obj.getClass().getName());
= }
=
=Maybe you should consider using instanceOf

How do you use <instanceOf>?

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[zero]

(e-mail address removed) wrote in @g49g2000cwa.googlegroups.com:

Chiron Paixos posted:

=If you insist on using getClass() look at the following example which
=uses a Class object to print the Class name of an object:
=
= void printClassName(Object obj) {
= System.out.println("The class of " + obj +
= " is " + obj.getClass().getName());
= }
=
=Maybe you should consider using instanceOf

How do you use <instanceOf>?

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

if(obj instanceof MyClass)
System.out.println("the object is an instance of MyClass");

This won't work of course if you want the class name, in that case use
Chiron Paixos' code.

 

[Thomas Hawtin]

Using the == operator would probably also work:

if(xyz.getClass() == Abc.class) {
....

but I think using .equals() is safer.

Using == is the standard idiom. Using equals in this context makes the
code different and clutters. Using == also consistent with synchronising
to the class object, for instance by marking static methods with
synchronize.

Tom Hawtin

 

[Monique Y. Mudama]

How do you use <instanceOf>?

---Kevin Simonson

SpecialFoo myFoo = new SpecialFoo();

if (myFoo instanceof Foo)
{
doStuff();
}

 

[Roedy Green]

if (xyz.getClass() == Abc)

If Abc is a class you would normally write that as:

if ( xyz instanceof Abc )

or

if ( xyz.getClass() == Abc.class )

They have slightly different meaning.

see http://mindprod.com/jgloss/classforname.html

 

[kvnsmnsn]

Thanks for all the feedback! Your answers helped a lot.

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[Dave Glasser]

Using == is the standard idiom.

Says who?

Using equals in this context makes the
code different

Different? Uh, yeah, I suppose it is "different", but I'm not sure
what your point is.

and clutters.

That's in tbe eye of the beholder. It doesn't look all that cluttered
to me, and besides, I would tend to stick with code I felt was better
rather than code that seems less cluttered.

So I guess now I should explain why I think .equals() is preferable to
== in this context. The semantics of == are clearly defined. If a and
be are object references, then "a == b" is true iff both a and b refer
to the same physical object (or instance). So, given this:

String a = new String("abc");
String b = new String("abc");

the expression "a == b" will evaluate to false, barring compiler
optimizations.

The .equals() method OTOH is more forgiving; Its semantics are defined
by the implementing class within certain constraints, but basically it
is used to determine whether two objects are "equivalent".

So, given this code:

Foo a = new Foo();
Foo b = new Foo();

Is a.getClass() guaranteed to always return the *same* instance of
java.lang.Class that b.getClass() returns? I suspect that it is and
does, but I'm not familiar enough with the Java standard to say for
sure. So I use .equals() instead, and I don't give it a second
thought.

Using == also consistent with synchronising
to the class object, for instance by marking static methods with
synchronize.

Sorry, but you've lost me here. I don't see how the == operator has
anything at all to do with class-level synchronization.


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

 

[Darryl L. Pierce]

(e-mail address removed) wrote:
<snip>

Why aren't you using the instanceof keyword to check whether it's an
instance of a specific class?

 

[Thomas Hawtin]

21:51:43 +0100 in comp.lang.java.programmer:




Says who?

Lot's of code.

To check I just ran the following over the latest Java SE 6 snapshot:

find /mnt/small/mustang/b53/ -name "*.java" -exec grep -h \\.class {} \;
| grep if

There were some clusters of using .equals(), but by far and away the
winner was ==.

Different? Uh, yeah, I suppose it is "different", but I'm not sure
what your point is.

Different from the clear, majority of code.

That's in tbe eye of the beholder. It doesn't look all that cluttered
to me, and besides, I would tend to stick with code I felt was better
rather than code that seems less cluttered.

You aren't a big fan of operator overloading then? I don't understand
how there can be doubt whether using == or .equals() is cluttered,
particularly when surrounded by other parentheses.

So I guess now I should explain why I think .equals() is preferable to
== in this context. The semantics of == are clearly defined. If a and
be are object references, then "a == b" is true iff both a and b refer
to the same physical object (or instance). So, given this:

String a = new String("abc");
String b = new String("abc");

the expression "a == b" will evaluate to false, barring compiler
optimizations.

(False always, unless the compiler/runtime is very broken indeed.)

For Class, you need to understand what its identity means in order to
make proper use of the class. It is misleading to do something
explicitly with value that if it were necessary would invalidate really
standard stuff, such as synchronised static methods.

String is different. It's the normal case. You wouldn't (usually) use
the identity of a String object. For Class identity is important.

Tom Hawtin

 

[Darryl L. Pierce]

To check I just ran the following over the latest Java SE 6 snapshot:

find /mnt/small/mustang/b53/ -name "*.java" -exec grep -h \\.class {} \;
| grep if

There were some clusters of using .equals(), but by far and away the
winner was ==.

And did you make sure to differentiate its use on primitives (for which
..equals() isn't possible) and its use on object references?

 

[Dave Glasser]

Lot's of code.

To check I just ran the following over the latest Java SE 6 snapshot:

find /mnt/small/mustang/b53/ -name "*.java" -exec grep -h \\.class {} \;
| grep if

There were some clusters of using .equals(), but by far and away the
winner was ==.

That still doesn't make it the "standard idiom." In fact, the fact
that the Mustang snapshot, written by the High Priests of the Java
Language, contains *both* styles indicates, if anything, that there is
no "standard idiom."

Different from the clear, majority of code.

Uh, the Mustang snapshot in no way represents the "clear majority of
code."

You aren't a big fan of operator overloading then?

No, I wouldn't call myself one.

I don't understand
how there can be doubt whether using == or .equals() is cluttered,
particularly when surrounded by other parentheses.

..equals() may be *more* cluttered than ==, but it still looks
perfectly readable to me.

(False always, unless the compiler/runtime is very broken indeed.)

Here again, I don't know for sure, and I wouldn't make any
assumptions. I'd write my code to work the same in either case.

For Class, you need to understand what its identity means in order to
make proper use of the class. It is misleading to do something
explicitly with value that if it were necessary would invalidate really
standard stuff, such as synchronised static methods.

I think I see now your point about synchronization, and I don't buy
it. You're saying that:

if(a.getClass().equals(Abc.class)) {

is somehow "misleading"? Give me a break.

And for the record, I checked the Javadoc, and java.lang.Class does
not override the Object.equals() method, so it's effectively the same
as using ==. So you use your style and I'll use mine.

 

[Mike Schilling]

(e-mail address removed) wrote on 29 Sep 2005 12:06:30 -0700 in
comp.lang.java.programmer:



Use the class literal for Abc, which is Abc.class:

if(xyz.getClass().equals(Abc.class)) {
...

Using the == operator would probably also work:

if(xyz.getClass() == Abc.class) {
....

but I think using .equals() is safer.

They're equivalent; Class.equals() is implemented as object equality. "=="
is slightly faster, not that that's a compelling argument.

 

[steve]

They're equivalent; Class.equals() is implemented as object equality. "=="

is slightly faster, not that that's a compelling argument.

they are NOT the same.

== compares to see if they are the SAME OBJECT IN MEMORY
..equals() compares to see if they are the same value

try using it on a primitive or constant, then see if they are the same.
better still try comparing 2 intergers.

 

[Mike Schilling]

they are NOT the same.

== compares to see if they are the SAME OBJECT IN MEMORY
.equals() compares to see if they are the same value

try using it on a primitive or constant, then see if they are the same.
better still try comparing 2 intergers.

They are the same for Class instances, which was the subject being
discussed.

 

[steve]

They are the same for Class instances, which was the subject being
discussed.

I ran into this in a database photo album I wrote, it was a bugger of a mess
to track down & clean up.

the default implementation of equals() in java.lang object compares objects
by identity , not by equality.



equals() and == are not the same, and it is better people learn that from the
start, instead of introducing confusion and saying :
sometimes they maybe are ,
but sometimes they are maybe not.

Anyway you are entitled to code any way you so desire as am I.

 

[Mike Schilling]

equals() and == are not the same, and it is better people learn that from
the
start, instead of introducing confusion and saying :
sometimes they maybe are ,
but sometimes they are maybe not.

They are the same for Class instances, which was the subject being
discussed.

 

[Owen Jacobson]

They are the same for Class instances, which was the subject being
discussed.

Object#equals (Object) determines if another object is equivalent to
`this`. The intrinsic == operator determines if two objects are the same
object. These operations have distinct semantics, regardless of whether
`this` is a String, a Class, or an ArbitraryComplexObject.

The former can (and, as you've so helpfully pointed out, often is) be
implemented in terms of the latter, for objects with no sensible
definition of equivalence. This doesn't make them the same operation.