Enum Idiom Question

[Rhino]

That is actually a good question.

I am sure that you can find it in the JLS (Java Language
Specification).

Same in the enum JSR for Java 1.5.

You can also see it if you examine the generated byte code
or look at the source of Enum.java.

Neither should be necessary for such a basic question.

Heavy googling managed to find:

http://java.sun.com/docs/books/tutorial/reflect/special/enumSetGet.html

<quote>
Since the enum constants are singletons, the == and != operators may be
used to compare enum constants of the same type.
</quote>

But that was not obvious.

I am afraid that the answer is that most Java programmers either
use one of the first mentioned methods or know somebody that does.

Sorry, I didn't mean to make work for you. I assumed that was one of those
questions that you experts can answer off the top of your head

Thanks for your help!

 

[Rhino]

Yes, it does, and if you read the docs there you find:
public final boolean equals(Object other)
telling you that it cannot be overridden and that it "returns true if the
specified object is equal to this enum constant."

From the definition of what an enum is in the language, you know that
there can only be one instance of an enum constant. Ergo, the only way
that an enum's 'equals()' method can return 'true' is if object identity
holds, and therefore the enum's 'equals()' method is functionally
equivalent to '=='.

Even without that, you know that the 'equals()' method is safe to use.

Thank you!

 

[Rhino]

By "the docs" I'm referring to the JLS and the Javadocs, which are the
primary sources. They don't quite cover everything, but they are
canonical as far as they go.

To whit, the chapter of the language spec that actually defines enums:
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9>
says, in paragraph 2 of the first "Discussion" sidebar,

"Because there is only one instance of each enum constant, it is
permissible to use the == operator in place of the equals method when
comparing two object references if it is known that at least one of them
refers to an enum constant. (The equals method in Enum is a final method
that merely invokes super.equals on its argument and returns the result,
thus performing an identity comparison.)"

Thank you.

 

[Rhino]

The dichotomy is not between "minor" and "severe" but between "in band"
and "out of band".

You misconstrue if you think that there is a "minor" or "severe"
"problem".

The design decision, and the point of divergence of opinion, is what
constitutes "in" or "out of" band.

If you design that bad inputs are "in band", bad input won't throw an
exception.
If you design that bad inputs are "out of band", bad input will throw an
exception. Then you decide between checked and runtime exceptions.

The degree to which the exception propagates, and the decision about in or
out of band, depend in part on how low-level the routine in question is.

There are different strategies for logging, too.

As long as you ask the good questions, e.g., "Is bad input in band or out
of band?", you'll tend make good decisions either way. Bad questions, "Is
bad input minor or severe?", tend to lead to bad decisions either way.

Well, perhaps the "in band/out of band" dichotomy is a better way to phrase
my question. But I had not heard this specific terminology before so it
didn't come to mind when I was writing the post.

I'll try to keep in mind that you prefer this terminology over other words
and phrases.

 

[Lew]

http://java.sun.com/docs/books/tutorial/java/javaOO/enum.html

Interestingly, this link does not address the OP's concern.

One wonders why it was offered.

 

[Rhino]

Interestingly, this link does not address the OP's concern.

One wonders why it was offered.

That's one of the things I read in trying to find my own answer and I didn't
see the right operator to use for testing equality there either, which is
why I posted in the first place....

 

[Lew]

I think I actually saw it first in "Java in a Nutshell" - OK as a quick
reference but not a great learning book.

"Effective Java" is IMO a goldmine. Also "Java Generics & Collections"
and "Java Concurrency in Practice".

The free chapter of /Effective Java/ (You hear that, Rhino? Free!)
<http://java.sun.com/docs/books/effective/toc.html>
<http://java.sun.com/docs/books/effective/generics.pdf>

is the best explanation of Java generics I've encountered, save perhaps for
Brian Goetz's articles on DeveloperWorks, also free. (You hear that, Rhino?
Free!)
<http://www.ibm.com/developerworks/java>

enums:
<http://www.ibm.com/developerworks/java/library/j-enums.html>
<http://www.ibm.com/developerworks/java/library/j-tiger04195/>

Brian Goetz:
<http://www.ibm.com/developerworks/s...W&searchScope=javaZ&query=Goetz&Search=Search>
<http://www.ibm.com/developerworks/edu/j-dw-java-generics-i.html>
<http://www.ibm.com/developerworks/library/j-jtp01255.html>
<http://www.ibm.com/developerworks/java/library/j-jtp0618.html>
<http://www.ibm.com/developerworks/java/library/j-jtp04223.html>
<http://www.ibm.com/developerworks/java/library/j-jtp09275.html>

 

[John B. Matthews]

I think I actually saw it first in "Java in a Nutshell" - OK as a quick
reference but not a great learning book.

"Effective Java" is IMO a goldmine. Also "Java Generics & Collections"
and "Java Concurrency in Practice".

The free chapter of /Effective Java/ (You hear that, Rhino? Free!)
<http://java.sun.com/docs/books/effective/toc.html>
<http://java.sun.com/docs/books/effective/generics.pdf>[/QUOTE]

Also free, the book's first six items in "Objects: Part 1 & 2"

<http://www.drdobbs.com/java/208403883>