enumerated types : Java Glossary

1. 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.
2. 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.
3. 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.