Backward-incompatible behaviour of 2.8: deserializing enum types with two static factory methods fail by default

[flozano]

After upgrading to 2.8, I'm getting:

com.fasterxml.jackson.databind.JsonMappingException: Conflicting String creators: already had explicitly marked [method com.company.MyType#valueOf(1 params)], encountered [method com.company.MyType#fromString(1 params)]

Whereas in previous (2.7.x) it worked well.

The enum is defined as:

public enum MyType {

    V1("val1"),
    V2("val2"),
    V3("val3"),
    V4("val4"),
    V5("val5"),
    V6("val6");

    private final String name;

    MyType(String name) {
        this.name = name;
    }

    public static MyType fromString(String name) {
        for (MyType type : MyType.values()) {
            if (type.name.equals(name)) {
                return type;
            }
        }
        // In case no matching delegate to default parser which will throw a
        // IllegalArgumentException if it's unable to parse the name
        return MyType.valueOf(name.toUpperCase());
    }

    @Override
    public String toString() {
        return name;
    }
}

[cowtowncoder]

Interesting. Thank you for reporting this; it is a flaw and change is unintentional. Not sure how it came about: static methods should not be auto-detected (unlike possibly single-string-constructors) but should require @JsonCreator. Possibly this is due to now skipping of constructor detection for enums (which caused another issue).

[cowtowncoder]

One quick note: a work-around is to explicitly annotate the creator with @JsonCreator: this removes ambiguity.

Problem itself comes from valueOf(), generated automatically by Java compiler (for enum types), being implicitly found; and then Jackson also accepting fromString(String), and because both are implicit, deserializer creator considers it ambiguous. What is less clear is how and why did 2.7 and earlier NOT fail with this one.

I'll try to find an improvement to alleviate the need, but I think addition of @JsonCreator actually makes sense here regardless.