Enumerated Types In Java

The following discussion is referring to Java 1.4 and earlier.

http://developer.java.sun.com/developer/bugParade/bugs/4401321.html also has a lengthy (and rather unproductive) discussion on the subject.

One of the things that I found surprising while learning Java is that it doesn't support C's enum keyword, which provides a mapping for an ordered set of constants. In the February 1997 issue of the JavaReport, ScottOaks presents a cute way of doing what are in effect enums in Java, which EricWhite? elaborates on in the September issue.

The basic idea is this -- create a class (say called Month) that has a set of private static int mappings for your "base" types. e.g.,

  private static int jan = 1;
  private static int feb = 2;
  // ...

  public static Month JAN = new Month(jan);
  public static Month FEB = new Month(feb);
  // ...

  protected static Month[] elements = {JAN, FEB, MAR, ...

This is a pretty cool implementation of the FlyweightPattern that gives you a lot of flexibility in building these enumerated types -- much more so than C's enum construct. It leaves you thinking how you ever got along using the clunkier way of doing things!

KyleBrown

 /* File: Months.java */
 /* Enumeration of internal states */
 import java.util.Enumeration;
 public class Months {
   public static String [] months = { "JAN", "FEB" , "MAR" };
   public static Enumeration elements() {
	return new MonthsEnumerator();
   }
 }

 class MonthsEnumerator implements Enumeration {
   private int idx = 0;
   public /*static*/ boolean hasMoreElements() {
 	return (idx < Months.months.length);
   }
   public /*static*/ Object nextElement() {
 	return Months.months[idx++];
   }
 }

Bernhard Kanz (bernhard@fh-rosenheim.de)

  class MyColor {
    public static final MyColor RED = new MyColor();
    public static final MyColor GREEN = new MyColor();
    public static final MyColor BLUE = new MyColor();
    protected MyColor() {}
  }

Be aware that enums were left out of Java for a reason: they are not very extendable. Code like:

  if (color == MyColor.RED) {
    // ...
  } else if (color == MyColor.GREEN) {
    // ...
  } else // (color == MyColor.BLUE) {
    // ...
  } 

Okay - so why not add the state data to Dave's implementation. We dont have to care about the values but we might still care about their order and sequence. We can have a protected class constant that is initialized to zero that essentially serves as an instance counter. Each instance initializes its color value with the instance count:

  class Color {
    protected static int numColors = 0;
    protected static Vector colorVector = new Vector();

    private int	colorNumber;
    private String  colorName;

    protected Color(String name) {
      this.colorName = name;
      this.colorNumber = numColors++;
      colorVector.addElement(this);
    }

    public String name() { return this.colorName; }
    public int ord() { return this.colorNumber; }	

    public static final Color RED = new Color("RED");
    public static final Color YELLOW = new Color("YELLOW");
    public static final Color BLUE = new Color("BLUE");

    // ...
  }

This wont have the persistence problems that Bill mentioned. It can also be easily extended by creating more static instances of the class (or a subclass) to add more colors (with unique values) for all of them (but they dont have too much control over the ordering of the new colors with respect to the existing ones, they will always come later-on in the color-number range). Of course you should probably pass the currently known range-size to the vector constructor for efficiency reasons.

In fact, I think this comes closest to getting the full range of 'enum' functionality in C++ (if that is indeed what you want). One could create a second constructor which also lets you specify the value to use for the instance being created. The class "instance counter" would instead simply be a "next value to use" and would always be "one plus the last value used" (which of course would be the default for the next instance that did not explicitly specify a value):

  class Color {
    protected static int sequenceNum = 0;
    protected static Vector colorVector = new Vector();

    private int	colorNumber;
    private String  colorName;

    protected Color(String name) {
      this.colorName = name;
      this.colorNumber = sequenceNum++;
      colorVector.addElement(this);
    }

    protected Color(String name, int number) {
      this.colorName = name;
      this.colorNumber = sequenceNum = number;
      ++sequenceNum;  // set default for next instance
      colorVector.addElement(this);
    }

    // ...
  }

-- BradAppleton

If you use a vector, you can use colorVector.size() instead of numColors. Arguably this makes clearer the class invariant that "colorVector.elementAt(i).colorNumber == i". Your last example no longer provides that guarantee, which is probably a bug. -- DaveHarris

This way of implementing enums in Java is great, and I've even written a little compiler to automate the task (and to test a lexer/parser package I have written). However, they have the disadvantage that they are not Serializable or Externalizable and cannot readily be made so. E.g: adding implements Serializable will not do the trick.

Instead, the handle/body idiom needs to be used. The handle is what clients see as the "enum" while the body holds the values of the enumerated constant. The body class is implemented as shown above, and so provides the limited set of predefined enum values. As many handles can be created as necessary and each is initialised with one of the body objects as its value. The handle is Serializable or Externalizable: it's write method writes the int value of its body object to the stream while its read method reads an int value from a stream and then translates that into the appropriate body object.

-- NatPryce

They thought of this. You must implement the readResolve() method, which allows the deserialized object to substitute another object in place of itself. Add the following method to Brad's first example:

    public Object readResolve() throws java.io.ObjectStreamException {
        Enumeration e = colorVector.elements();
        while (e.hasMoreElements()) {
            Color c = (Color)e.nextElement();
            if (colorNumber == c.colorNumber) return c;
        }
        throw new java.io.InvalidObjectException("Invalid colour value");
    }

I've seen several pieces of C code that implement Pascal-style enumerated types. In Pascal you can write a for loop that uses the order in which enumerated identifiers are declared within an enumerated type. I don't like the way this tends to get used.

Consider:

  enum hobbs { hobbAikido, 
               hobbRocketCatching,
               hobbMountainClimbing,
               hobbVaxRestoration}

  for (i = hobbAikido; i <= hobbVaxRestoration; ++i) {
    // ... do whatever...
  }

 enum hobbs { hobbAikido, 
              hobbFirst = hobbAikido,
              hobbRocketCatching,
              hobbMountainClimbing,
              hobbVaxRestoration,
              hobbTormenting,
              hobbLast = hobbTormenting}

 for (i = hobbFirst; i <= hobbLast; ++i) {
   // ... do whatever...
 }

 for (i = hobbLast; i <= hobbFirst; i--) {
   // ... do in reverse order of hobbies
 }

Does anybody know if the official C/C++ standards allow this type of usage? I've looked at K&R's Ansi C book and I can't see objections to this style of enum in there. I hope it's not just an "accident of gcc".

--DafyddRees

It's guaranteed by C++. Nowadays one might write an iterator template in the STL style, or at least use ++i instead of i++ :-) -- DaveHarris

See also DefineConstantsInInterfaces.

I like Brad's way of doing this. But what particularly peeves me about Java is that statics are not inherited properly. In other words, I'd like to define an Enum superclass, along the lines of:

 public abstract class Enum {

   private int number;

   private string name;

   private static Vector itemVector = new Vector();

   protected Enum (String name) {
     this.name = name;
     this.number = itemVector.size();
     itemVector.addElement(this);
   }

   public String getName() { return this.name};
   public int getNumber() { return this.number};
 }

JaredNedzel?

I can think of two ways, off the top of my head...

1) Use the TemplateMethodPattern in the Enum class to get a reference to the static vector used by a concrete class.

 public abstract class Enum {
   private int number;
   private string name;

   protected Enum (String name) {
     this.name = name;
     this.number = itemVector().size();
     itemVector().addElement(this);
   }

   public String getName() { return this.name };
   public int getNumber() { return this.number };

   protected abstract Vector itemVector();
 }

 public class Month extends Enum {
   private static Vector items = new Vector();

   public static Month JAN = new Month();
   // ... etc ...

   protected Vector itemVector() { return items; }
 }

 public abstract class Enum {
   private int number;
   private string name;

   private static Hashtable vectors = new Hashtable();

   protected Enum (String name) { 
     this.name = name;
     this.number = itemVector().size();
     itemVector().addElement(this);
   }

   public String getName() { return this.name };
   public int getNumber() { return this.number }; 

   private abstract Vector itemVector() {
      Vector vec = (Vector)vectors.get( getClass() );
      if ( vec == null ) {
          vec = new Vector();
          vectors.add( getClass(), vec ); 
      }
      return vec;
   }
 }

JochenBedersdorfer

1) as Brad's example illustrates, add an "ordinal" or "number" parameter to the constructor, such that part of instantiating an instance of a EnumeratedType? subclass is to provide the instance's ordinal. Write your constant initialization expressions to pass both the ordinal and the name.

2) as illustrated in Kyle's initial posting, define one set of constants that establish the ordinal values and a second set of constants with instances of the class bound. The first set of constants become arguments to the instantiation of the second set.

3) use a static initializer in subclasses to force instantiation of instances in a specific, predictable order (in which case you wouldn't need the additional parameter on the constructor). I have mixed feelings about this solution, as I guess I haven't gotten comfortable with using static initializers (lingering Smalltalk biases perhaps).

Does anyone have any opinions about which of these approaches is better, or have additional alternatives?

DaveMuirhead

1. The constructor only needs to be passed the instance's name if you need toString. If you don't need toString, skip the name.
2. Very often you don't really need the value. In that case, don't have the constructor take a value.
3. If the instances need a value and that value can be automatically generated (by auto-increment, for example), then you probably don't really need the value.
4. If the instances really do need a value, just pass it into the constructor. Don't define another named constant for it.

I just want to add a remark to the enum implementations presented at the beginning of this page. There is one thing why I don't like them very much. Returning a human-readable version of an enum doesn't make much sense if you have to do internationalization and localization. One common design rule in I18N/L10N is, that you do conversion from/to local-specific representations on the "borders" of the application only. That is, where data is entered, and where data is displayed (in the GUI). Internally, one just uses local-independent information. So you are able to concentrate on a very few spots in a large application.

Having enums which have an own representation deep down in the code just makes things harder.

I disagree with the above... First of all, I18N/L10N tackles the presentation portion of an application, so effectively enums do not cross that boundary. Finally, if source codes were to be "I18N/L10N"-ed, then we shouldn't code in Java at all since the language's in English, not in our mothertongue....

Taking the example (just) above, the GUI is localized, but the parameters passed in to construct the GUI is (gasp!) still in English!!! (e.g. BorderLayout.PAGE_START)

And what's wrong with human-readable source codes? Every programmer knows how to code, but only those who are good write human-readable ones... [a quote i can't remember who to give credit to]

Therefore, enum, when used properly, is a good thing.....

 import java.util.Arrays;
 import java.util.Collections;
 import java.util.Iterator;
 import java.util.List;

 /**
  * A typesafe enumeration of the months.
  * 
  * Immutable, Thread safe, and resolves properly on deserialization.
  *
  */
 public final class Month implements Comparable, java.io.Serializable {
	// Public constants

	public static final Month JAN = new Month("January");
	public static final Month FEB = new Month("February", 28);
	public static final Month MAR = new Month("March");
	public static final Month APR = new Month("April", 30);
	public static final Month MAY = new Month("May");
	public static final Month JUN = new Month("June", 30);
	public static final Month JUL = new Month("July");
	public static final Month AUG = new Month("August");
	public static final Month SEP = new Month("September", 30);
	public static final Month OCT = new Month("October");
	public static final Month NOV = new Month("November", 30);
	public static final Month DEC = new Month("December");

	private static final Month[] MONTH_ARRAY =
		{ JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

	public static final List MONTHS =
		Collections.unmodifiableList(Arrays.asList(MONTH_ARRAY));

	// Month implementation

	// count will be seen as zero despite its value unless it's before the
	// public constant declarations
	private static int count = 0;

	final String name;
	final int number;
	final int days;

	private Month(String name) {
		this(name, 31);
	}

	private Month(String name, int days) {
		this.name = name;
		this.days = days;
		this.number = ++count;
	}

	public String getName() {
		return name;
	}

	public String getAbbev() {
		return name.substring(0, Math.min(3, getName().length()));
	}

	public int getNumber() {
		return number;
	}

	public int getDays() {
		return days;
	}

	public String toString() {
		return name;
	}

	public int compareTo(Object o) {
		return getNumber() - ((Month) o).getNumber();
	}

	Object readResolve() throws java.io.ObjectStreamException? {
		return MONTH_ARRAY[number - 1];
	}
 }

You can also use the enumeration classes in the Jakarta Commons Lang project at http://jakarta.apache.org/commons/lang.html. Look for Enum, ValuedEnum, and EnumUtils. Strangely enough, to avoid class loader problems, you should test these enumerations for equality using equals, not == so long as you account for the fact that classes loaded from different classloaders are not equal.

They give this example:

  public final class ColorEnum extends Enum {
    public static final ColorEnum RED   = new ColorEnum("Red");
    public static final ColorEnum GREEN = new ColorEnum("Green");
    public static final ColorEnum BLUE  = new ColorEnum("Blue");

    private ColorEnum(String color) {
      super(color);
    }

    public static ColorEnum getEnum(String color) {
      return (ColorEnum) getEnum(ColorEnum.class, color);
    }

    public static Map getEnumMap() {
      return getEnumMap(ColorEnum.class);
    }

    public static List getEnumList() {
      return getEnumList(ColorEnum.class);
    }

    public static Iterator iterator() {
      return iterator(ColorEnum.class);
    }
  }

The Enum class was written by Stephen Colebourne.

-- EricJablow

  http://www.langrsoft.com/articles/enum.html

--JeffLangr

This page mirrored in JavaIdioms as of April 29, 2006