Did You Know enums Can Define Their Own Methods?

… I sure as hell didn’t, but found myself in a position the other day where I was thinking “Damn, I wish I could define a common method in this enum that I could call and not have to write another utility method…” Well, ask and ye shall receive… or something like that.

Here’s the enum I had defined in one of my classes:

public static enum EventType {
    COMPONENT_ADDED,
    COMPONENT_REMOVED
}

It’s fairly straight forward what I was using it for — every time I fired an event of a certain type, I always make sure to set the type on the event, so the receiver knows what to do with it.

The situation I found myself in, is similar to MouseEvent‘s use of the BUTTON constants in that when a new event of the specific type is created, the only valid eventType arguments allowed should be of ones defined in the enum itself.

NOTE: As I write this, it just dawned on me that this specific example is an invalid use-case, but I’m still going to finish the example because it’s really cool that you can define methods inside of enums. For those that haven’t caught my mistake yet, I’ll explain why this example is invalid at the end of the article.

In order to guarantee that the provided eventType is part of the defined enum, I sat down and started to write a simple boolean contains(EventType eventType) method in the parent event class… it was then that I realized “this feels wrong, this method that checks contains state should be defined in the enum itself — it’s the logical place one would look for such a thing”

After some digging online, it turns out defining methods inside enums is completely valid, becuase they are essentially classes. What I ended up with is the following:

public static enum EventType {
    COMPONENT_ADDED,
    COMPONENT_REMOVED;
    public static boolean contains(EventType eventType) {
        boolean contains = false;
        EventType[] values = EventType.values();
        for (int i = 0; i < values.length && !contains; i++) {
            contains = (COMPONENT_ADDED.equals(values[i]) || COMPONENT_REMOVED
                    .equals(values[i]));
        }
        return contains;
    }
}

So now when I receive an eventType in the constructor of the parent event, I can check it with a simple:

if(!EventType.contains(eventType))
    throw new IllegalArgumentException();

Very cool stuff.

CLARIFICATION: For those that didn’t catch my mistake with this example, you’ll notice the entire purpose for writing the contains(EventType eventType) method in the EventType enum is to verify that a given instance of EventType was defined in the enum — the answer is “of course it has been” — the only value I have to check for is null, if the value of the eventType argument is not null, it’s already guaranteed that it is a valid value from the enum, because it is an instance of the enum — so there is no need to check.

Even though I mad that glaring mistake with this example, I don’t want to think of another example on the fly that is more applicable, or dumb this one down to something really generic like the classic fruit-type example — instead the information provided should still be helpful if you are curious about learning about enums in Java 5 or later in more detail.

ADDITIONAL NOTE: I’m always surprised at the number of people that don’t know about using multiple-conditions in the standard for-loop above. It’s an awesome way to short-circuit an itteration when you find what you want.