enumerated types : Java Glossary

Prior to Java version 1.5 does not have enumerated types the
way Pascal and C++ do. With 1.5 there are now
enums. There are
three ways to get around the problem:

Create a Vegetable class just to hold your collection of public static final
int constants that encode the possibilities. In simple cases you don’t bother
with a separate Vegetable class for your constants. You just define them in the
JuiceBar class. The disadvantages of this method are:

You just close your eyes to parameter type checking. To the compiler any
int will do as a parameter to a method expecting a Vegetable code. It does not
care if you pass a Vegetable code, or diameter in millimeters

You have to manually assign numbers to each option.

Create a Vegetable class to contain your collection of various named static
final objects to represent each possibility. The main problems
with this method are:

Extra run time overhead.

You have to create a separate Vegetable class. You can’t just
piggyback the constants inside the JuiceBar class that uses them.

You can’t use your possibility constants in a switch statement. You
need to code with nested ifs and ==.

It is difficult to store data externally, especially if you add or delete
possibilities and need to update existing databases.

Similar to the second approach, but this time we arrange to make the
enumerations Serializable. The advantage are it is type safe and Serializable. The
main problems with this method are:

Extra run time overhead.

You have to create a separate Vegetable class. You can’t just
piggyback the constants inside the JuiceBar class that uses them.

You can’t use your possibility constants in a switch statement. You
need to code with nested ifs and ==.

You need to write a lot of code to convert back and forth between int and
Object form.

JavaWorld Magazine did an article on various ways to kludge enumerations in Java. Philip Bishop did an article on a type-safe scheme for both C++ and
Java. John D. Mitchel did an article on a scheme using the C preprocessor.

I wrote a proposal to properly build in two types of enumerations into the Java
glossary. I doubt we will ever have decent enumerations. The theoreticians seem to
think the coming genericity features of Java will be sufficient. Arrgh! They
don’t care how verbose the code is.

Perhaps what we could do in the interim is use a combined approach with even more
bells and whistles including a set of static final ints you can use as case labels.
You also need some external representations for use in an external database, often a
single character or a short string. These representations are more immune to breaking
your database when you add a new enum element. You use an amanuensis to stomp out the
repetitive code with a cookie cutter. You enter svelte Pascal and out pops Divine
Java.