enum equality?

[Knute Johnson]

What is the correct method to test equality with an enum, == or .equals?

Thanks,

 

[Chris Uppal]

What is the correct method to test equality with an enum, == or .equals?

For most purposes == is correct.

It's the nature of "enum"[*] objects that each object is distinct and, in some
sense, unique (sort of like the Singleton pattern). So you will normally want
to compare the identity of two object references -- hence ==.

-- chris

[*] rather a misleading name since it suggests a non-existent similarity to C
or C++'s enums.

 

[Knute Johnson]

What is the correct method to test equality with an enum, == or .equals?

For most purposes == is correct.

It's the nature of "enum"[*] objects that each object is distinct and, in some
sense, unique (sort of like the Singleton pattern). So you will normally want
to compare the identity of two object references -- hence ==.

-- chris

[*] rather a misleading name since it suggests a non-existent similarity to C
or C++'s enums.

Thanks Chris.

 

[Oliver Wong]

What is the correct method to test equality with an enum, == or .equals?

For most purposes == is correct.

It's the nature of "enum"[*] objects that each object is distinct and, in
some
sense, unique (sort of like the Singleton pattern). So you will normally
want
to compare the identity of two object references -- hence ==.

The two are *almost* equivalent. The java.lang.Enum class (which all
enums extend) makes the equals() method final, and the implementation is
"return this == other;".

The only situation I can think of where they differ is that an enum
reference may be null, and so the equals() method invocation may result in a
NullPointerException.

So I agree with Chris: == is probably what most people want most of the
time.

- Oliver

 

[Esmond Pitt]

What is the correct method to test equality with an enum, == or .equals?

== will do. There is a bug if you have deserialized the enum, otherwise
Java takes care that there is only one instance of each value.

 

[Andreas Leitgeb]

== will do. There is a bug if you have deserialized the enum, otherwise
Java takes care that there is only one instance of each value.

Please more info about that bug!

It would look like a very severe bug, if the property of enums
(that there can't ever exist any other instances than those
created at enum class initialization time) was so easily broken.

 

[Daniel Dyer]

Please more info about that bug!

It would look like a very severe bug, if the property of enums
(that there can't ever exist any other instances than those
created at enum class initialization time) was so easily broken.

There is this bug concerning IIOP, there may also be issues when IIOP is
not involved:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6277781

I worked around the problem by adding the following method to all enums
that are likely to be serialized:

private Object readResolve()
{
return valueOf(name());
}

It substitutes the correct enum constant in place of any deserialized enum
object with the same name.

Dan.

 

[Esmond Pitt]

Please more info about that bug!

It would look like a very severe bug, if the property of enums
(that there can't ever exist any other instances than those
created at enum class initialization time) was so easily broken.

It is in RMI/IIOP actually, not just Serialization per se, and it
requires an OMG CORBA Java/IDL specification update to fix it ;-)
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6277781
and http://forum.java.sun.com/thread.jspa?forumID=62&threadID=744600

 

[Andreas Leitgeb]

It is in RMI/IIOP actually, not just Serialization per se, and it
requires an OMG CORBA Java/IDL specification update to fix it ;-)
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6277781
and http://forum.java.sun.com/thread.jspa?forumID=62&threadID=744600

Thanks!

Serializing enums seems to be a fragile thing for enums
that have instance fields. Either the serialized objects
data or the target-JVM-objects data would need to get lost.
As it seems it's the original objects one for plain (non-
corba) serialisation. And it's a much worse mess with Corba
and the information bottleneck "sdl".