What's the deal with enums?

Question

Hello,
I'm trying to familiarise myself with the new Java features that project Tiger (Java 1.5) will introduce. I come from a C++ programming background. I very briefly studied enums whilst I learned C++ and never used them in my programs, so I was, quite frankly, relieved when I learned that Java didn't support them.
But now it does.
I'm wondering, from a software design and engineering perspective, what benefit enums will add to the Java language and software engineering in general. I have read some pleas and arguments for enums. As I understand those arguments, proponents feel that minor ledgibility improvements to switch statements (which some OO programmers don't use on the basis that it weakens the object-orientedness through its goto-esque break statements) necessitate the addition of a whole other structure.
Out of curiosity, wouldn't it be more advantageous for Sun to put their efforts into supporting constant strings in switches in addition to primitive data types if people are so concerned with clarity?
I fail to understand what enums will do that constant string arrays or constant values cannot. I would like to think that Sun wouldn't add C++ features unless if there was a reason to do so, so I believe that there are good reasons to introduce this feature.
Please help clarify this confusion.
Thank you!

Answer 1

Comments on the previous posting inline. Note: I'll go off on a few tangents, but try to always return to the issue of enums. The fact that I go off on tangents (related initially to an enum type example) should show that enums help eliminate numerous problems.
Fair enough, but wouldn't this accomplish the same thing in
a slightly wordier wayPretty much. But you still have the validation code in there yourself:
currentDirection = ( direction > 0 && direction < 5 ? direction : 0 );People can still accidentally enter an invalid value, and it won't get caught by the compiler. So, I could call set(Compass.WEST) and hope/expect that is equivalent to set(Direction.LEFT). This will only occur if both Compass.WEST and Direction.LEFT are the same int value. If they are not, then we are in trouble. Worse, still if Compass.WEST and Direction.RIGHT are the same value, the code will compile, and run without any illegal value flagging, but our traveller will go off in the wrong direction.
Error handling tangent: Given the implementation, the error handling is not performed in set, rather the illegal value is captured as a zero, which must be dealt with at a later time - say in a switch statement that calls get. This is not a good idea - it increases the "distance" between the error occuring (bad call to set) and the error being detected (if xInt != 0). The larger the distance, the harder debugging is. If you throw an exception in set the bug is immediately flagged. With enums, none of this should be necessary.
Implementation tangent: set, get and currentDirection are static. This is not a good idea - it only allows one direction. If you have multiple travellers, each would have a Direction object, but (sticking with constants) UP, etc. would still be static.
I keep the switch statement in my enum workaround, but I believe that
the second reply suggested that enum could altogether eliminate the
use for switch statements. How exactly would it do that?enum in its simplest form would not remove switch. However, using an extension of the type-safe enum idiom (i.e. the current Java approach to enums), you can embed direction specific logic in each of the "enum" members. If I understand the enum-spec correcly, this will also be possible with the Java 1.5 enum language facility.
So, for an example, sticking with the domain: Consider a class Location, with x and y elements, and a Direction. The non-OO, non-enum approach would be as follows:
class Location {
    int x,y;
    void move (final int direction) {
        switch (direction) {
            case UP:
                --y;
                break;
            case DOWN:
                ++y;
                break;
            case LEFT;
                --x;
                break;
            case RIGHT:
                ++x;
                break;
            default;
                throw new RuntimeException("Invalid direction " + direction);
class Direction {
    public static final int UP = 1;
    public static final int DOWN = 2;
    public static final int LEFT = 3;
    public static final int RIGHT = 4;
}Note that I've deliberately been loose with my visibility. All logic is in Location, and Direction is dumb. If we go with a type safe-enum idiom, we get:
class Location {
    int x,y;
    void move (final Direction direction) {
        if (direction == Direction.UP) {
            --y;
        } else if (direction == Direction.DOWN) {
            ++y;
        } else if (direction == Direction.LEFT) {
            --x;
        } else if (direction == Direction.RIGHT) {
            ++x;
        } else { // direction is null
            throw new NullPointerException("null direction");
class Direction {
    public static final Direction UP = new Direction();
    public static final Direction DOWN = new Direction();
    public static final Direction LEFT = new Direction();
    public static final Direction RIGHT = new Direction();
    private Direction () {} // the ctor is private to limit instances
}This code is a rewrite of the int approach, but is "type-safe". We've moved from switch to if as we can't switch on object references. Note: there is still error handling code, as you're not "null-safe" (I don't know what the Java 1.5 spec says about this)
Little else has changed - the responsibilities are still the same. We can address this by going OO, which removes the if (formerly a switch) statement, but does couple the classes.
class Location {
    int x,y;
    void move (final Direction direction) {
        direction.move(this);
class Direction {
    private final int xOffset, yOffset;
    private Direction (final int xOffset, final int yOffset) {
        this.xOffset = xOffset;
        this.yOffset = yOffset;
    public static final Direction UP = new Direction(0,1);
    public static final Direction DOWN = new Direction(0,-1);
    public static final Direction LEFT = new Direction(-1,0);
    public static final Direction RIGHT = new Direction(1,0);
    void move(final Location location) {
        location.x += xOffset;
        location.y += yOffset;
}This removes any conditional logic, embedding (constructor parameterised) logic within Direction. It also eliminates the "null-safe" check, as direction.move(this) will throw an NPE if a null is passed.
Also, I've read some things saying that enum reduces 'boilerplate'
code. What exactly does that and 'boilerplate' mean?The Direction class is an example of the type-safe enum approach currently used in Java. It has been enhanced with logic for movement. Even if I dropped this logic, there is still functionality worth adding to the Direction class - a toString method that returns one of "UP", "DOWN", etc (shown next); a way to serialize the object and retain reference equality - you have to write a readResolve method (not shown).
class Direction {
    private final String name;
    private Direction (final String name) {
        this.name = name;
    public static final Direction UP = new Direction("UP");
    public static final Direction DOWN = new Direction("DOWN");
    public static final Direction LEFT = new Direction("LEFT");
    public static final Direction RIGHT = new Direction("RIGHT");
    public String toString() {
        return name;
}Once you've written this code for one type-safe enum, you've written them for them all. You copy-cut-paste, and rename the class/elements. All this code is predictable. It is "boiler plate". Now, if you gave me a compiler that generated all this code for me, when I present it with
enum Direction {UP, DOWN, LEFT, RIGHT}; then I've got something that reduces my boiler plate code to zip.... Enter the Java 1.5 compiler.