Olli Plough <oliver@plohmann.com> wrote in news:6b5abf63-978a-49da-8fe0-
5deee7b94743@e67g2000hsc.googlegroups.com:

Oliver,

I don't know why (presumably there is a good reason), but I share your
annoyance.

In my own code base I tried to circumvent this "short coming"
by introducing a "PseudoEnum" class, that behaves as much as possible
like an enum, but is in fact an ordinary class and, as such,
extensible.

http://www.pbjar.org/docs/src/org/pbjar/resources/PseudoEnum.java

From the API documentation you may find some possible use cases.

http://www.pbjar.org/Docs/API-docs/index.html

Hope this helps

Piet

Just trying to think outside the box here a bit....

Have you looked into the EnumSet and the EnumMap classes? They are
supposed to be as fast as bit operations and array indexes for most
(presumably, relatively small, ie < 32 members) Enumerations.  They
should be faster that HashSet/HashMap.

Put your "extra" information into a lookup EnumMap with the key being
the Enum and your string info being the value.  Then you can hopefully
only declare your extra-info class once and reuse it every where.

This is basically late binding but this could have some advantages too.
 If you need to go the other way (look up the associated enum given the
value) just embed the enum into each class.

You might get away with instantiating this EnumMap once, per Enum, in
the declaration of the Enum class itself.  Depends on your design...

Suggestion: put your String information into a generic extra info class.
Parameterized it with an Enum (ie, class MyClass<ENUM> ... ) and then
you've got one class type per enum type to fool around with.

On Sun, 16 Dec 2007 05:53:42 -0800 (PST), Olli Plough
<oliver@plohmann.com> wrote, quoted or indirectly quoted someone who
said :

the key to understanding enums is to see how they are implemented as
ordinary classes under the hood.  All the weird rules derive from that
implementation.   See http://mindprod.com/jgloss/enum.html
to explain how the work.