Saving enum value using name()

Question

Let's assume I have an enum type

enum ComponentState {
    TURNED_OFF,
    TURNED_ON,
    SUSPENDED,
    TO_REPAIR;
}

This enum describes a state of some component. Now let's assume I want to export my component to as XML file. Then, of course, I'm going to import my component. So:

//Export:
componentElement.setAttribute("state", getState.name());  // results in <element state="TURNED_ON">

//Import
try {
   state = ComponentState.valueOf(element.getAttributeValue("state"));
} catch (IllegalArgumentException e) {
   //... 
}

Everything is fine, but problems starts when I change the name of some enum constants, because it sounds better:

enum ComponentState {
    TURNED_OFF,
    TURNED_ON,
    SLEEPING,   // <- the same sense, but
    CRASHED;    // <- different name (PM's "I want to have")
}

Note, that doing this I'm loosing a backward compatibility.

Question: How do you cope normally with such situations?

1

public String getXMLValue(){
    // ... implementation independent from name()
}

and

static ComponentState parseXMLString(String s) {
    // ... checking if s matches any name()
} 

OR

2

My approach is OK - it should not be expected, that the name on enum will change just because it sounds better.

Answer 1

A standard way to do this is to introduce a static method in addition to valueOf(...) that goes something like:

import java.util.HashMap;
import java.util.Map;


public enum DummyEnum {

    TOM, DICK, HARRY;

    private static final Map<String, DummyEnum> FUZZY = buildMap();

    private static Map<String, DummyEnum> buildMap() {
        Map<String, DummyEnum> mapto = new HashMap<>();
        mapto.put("OTOM", TOM);
        mapto.put("ODICK", DICK);
        mapto.put("OHARRY", HARRY);
        for (DummyEnum de : values()) {
            mapto.put(de.name(), de);
        }
        return mapto;
    }

    private static final DummyEnum fuzzyValueOf(String name) {
        return FUZZY.get(name);
    }

    public static void main(String[] args) {
        System.out.println(DummyEnum.fuzzyValueOf("OHARRY"));
        System.out.println(DummyEnum.fuzzyValueOf("HARRY"));
    }

}

You can change what goes in the buildMap method to suit your needs.... pull data from a database, a config file, whatever.

Note that the valueOf() method throws an exception for invalid names, but the fuzzyValueOf() will return null.

Answer 2

I like rolfl's approach, but I have one thing to add which would make it more compact and flexible:

Use a private constructor to provide a custom save value.

The biggest benefits of using either my or rolfl's approach is that you don't need to remember to add new enum values to the HashMap. In my approach especially, it gives you a clear overview of the enum values with their corresponding save values. As long as you only use one constructor (which I highly recommend) it is impossible to forget to give a save value for the enum.

This approach also allows you to customize their save-values much easier. You can rename your enums all you want, all you need to remember is to not change the saveValue, unless you want incompatibility issues.

enum ComponentState {
    TURNED_OFF("off"),
    TURNED_ON("on"),
    SUSPENDED("susp"),
    TO_REPAIR("repair");

    private final String saveValue;

    private ComponentState(String saveAs) {
        this.saveValue = saveAs;
    }

    private static final Map<String, ComponentState> FUZZY = buildMap();

    private static Map<String, ComponentState> buildMap() {
        Map<String, ComponentState> mapto = new HashMap<>();
        for (ComponentState state : ComponentState.values()) {
            mapto.put(state.saveValue, state);
        }
        return mapto;
    }

    private static final ComponentState fuzzyValueOf(String name) {
        return FUZZY.get(name);
    }

    public String getSaveValue() {
        return this.saveValue;
    }
}

---

If you want to have multiple possible save values for the same enum, then use a String... parameter: (However, in this case you need to make sure that you don't use an empty constructor for a field, as that wouldn't give it a specified save value)

    private final String[] saveValues;
    private ComponentState(String... saveAs) {
        this.saveValues = saveAs;
    }
    public String getSaveValue() {
        return this.saveValues[0];
    }

---

I really can't recommend using the .ordinal approach as ratchet freak suggested, even though it is nice and tidy, consider this enum:

Suit {
    DIAMONDS, HEARTS, SPADES, CLUBS;
}

Now what if you'd like to re-order them?

Suit {
    CLUBS, SPADES, DIAMONDS, HEARTS;
}

Congratulations, spades has become diamonds, clubs is hearts. Down is up and up is down. Logic goes on ski vacation with it's buddy reason.

If you use the .ordinal approach, remember to never ever ever switch places of them. (Me, talking from experience? What makes you think that?)

Answer 3

instead of the name of the enum you can save the ordinal

//Export:
componentElement.setAttribute("state", getState.ordinal());  // results in <element state="1">

//Import
try {
   state = ComponentState.values()[Integer.parseInt(element.getAttributeValue("state"))];
} catch (ArrayIndexOutOfBoundsException e) {
   //... 
} catch (NumberFormatException e) {
   //... 
}

this makes the code independent of the name but will make it dependent on the order the enums are declared in. and makes the file less human readable

Answer 4

If you are using Java 7 or later, a really concise string-to-enum translation method using a can be constructed using a switch statement:

public static ComponentState toEnum(String name) {
    if (name == null) {
        return null;
    }

    switch(name) {
    // handle removed enum values
    case "SUSPENDED":
        return ComponentState.SLEEPING;
    case "TO_REPAIR":
        return ComponentState.CRASHED;

    // revert to normal translation
    default:
        return ComponentState.valueOf(name);
    }
}