Java Glossary : enumerated types

CMP home Java glossary home Menu no menu Last updated 2004-06-28 by Roedy Green ©1996-2004 Canadian Mind Products

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : E words : enumerated types.

enumerated types
Prior to Java 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:
  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.

    public class Vegetable
       {
       public static final int unknown = 0;
       public static final int beet = 1;
       public static final int broccoli = 2;
       public static final int carrot = 3;
       } // end class Vegetable
    public class JuiceBar
       {
       public void mixIn (int v)
          {
          switch ( v )
             {
             case Vegetable.broccoli: /* ... */ break;
             case Vegetable.carrot: /* ... */ break;
             default: /* ... */
             }
          } // end mixIn
       } // end class Juicebar
    

  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.

    public class Vegetable
       {
       protected Vegetable()
          {
          // constructor has no fields to initialise
          }
       public static final Vegetable unknown = new Vegetable();
       public static final Vegetable beet = new Vegetable();
       public static final Vegetable broccoli = new Vegetable();
       public static final Vegetable carrot = new Vegetable();
       } // end class Vegetable
    public class JuiceBar
       {
       public void mixIn (Vegetable v)
          {
          if ( v == Vegetable.broccoli )
             {
             /* ... */
             }
          }
       // ...
       } // end class JuiceBar
    

  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.

    // Scott Andrew Borton approach
    public class Vegetable implements Serializable
       {
       private final int _type;
       protected Vegetable (int type)
          {
          _type = type;
          }
       public static final Vegetable unknown = new Vegetable(0);
       public static final Vegetable beet = new Vegetable(1);
       public static final Vegetable broccoli = new Vegetable(2);
       public static final Vegetable carrot = new Vegetable(3);
       private static final Vegetable[] vals =
       {
          unknown, beet, broccoli, carrot
       };
       private Object readResolve() throws ObjectStreamException
       {
          return vals[_type];
       }
       }
    // end class Vegetable
    

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.


CMP logo
CMP_home
home
Canadian Mind Products CSS
HTML Checked!
ICRA ratings logo
mindprod.com IP:[24.87.56.253]
Your IP:[80.134.30.163]
You are visitor number 2461.
Please send errors, omissions and suggestions
to improve this page to Roedy Green.
You can get a fresh copy of this page from: or possibly from your local J: drive mirror:
http://mindprod.com/jgloss/enumeratedtypes.html J:\mindprod\jgloss\enumeratedtypes.html