Deserialization of enums with name defined with different cases leads to `InvalidDefinitionException`: Multiple fields representing property

[sbailliez]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

I'm using a thirdparty client that is deserializing json where an enum is made of variations like RGBA and RGBa. When upgrading our dependencies from Jackson 2.14.1 to 2.16.1 this API started failing with

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Multiple fields representing property "rgba" ...

Version Information

2.16.1

Looks like the bug was introduced in 2.16.0 as it works with 2.15.4

Reproduction

    public static class Bug {
        public enum ColorMode {
            RGB, RGBa, RGBA
        }
        public ColorMode colorMode;
    }

    @Test
    public void enumFails() throws Exception {
        String json = "{ \"color_mode\": \"RGBa\"}";
        ObjectMapper mapper = new ObjectMapper();
        mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
        mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
        Bug bug = mapper.readValue(json, Bug.class);
    }

Expected behavior

This should succeed.

Additional context

For this particular, I worked around this issue right now by patching the objectmapper created within the client and adding a custom deserializer for that enum:

    public static class EnumDeserializer extends StdDeserializer<File.ColorMode> {
        public EnumDeserializer() {
            this(null);
        }

        public EnumDeserializer(Class<?> vc) {
            super(vc);
        }

        @Override
        public File.ColorMode deserialize(JsonParser p, DeserializationContext ctxt) throws IOException, JacksonException {
            JsonNode node = p.getCodec().readTree(p);
            String value = node.asText();
            return value != null ? File.ColorMode.valueOf(value) : null;
        }
    }
    
    // .... reflective access to find the objectmapper in the thirdparty client...
    mapper.registerModule(new SimpleModule("patch-enum")
         .addDeserializer(File.ColorMode.class, new EnumDeserializer()));

[cowtowncoder]

Thank you for reporting this, @sbailliez ! It definitely looks like a bug.

Two immediate guesses for possible triggering part (will try to see if they are related).

1. Use of naming strategy would trigger bogus conflict
2. Case-insensitivity incorrectly enabled by some processing resulting in bogus conflict.

[cowtowncoder]

Yes, looks like PropertyNamingStrategy is triggering the issue.

Possibly related:

• Problem deserializing some type of Enums when using PropertyNamingStrategy #4302
• Fix Enum deserialization to use @JsonProperty, @JsonAlias even if EnumNamingStrategy used #4037 / Use @JsonProperty over EnumNamingStrategy for Enum serialization #4040
• Add @EnumNaming, EnumNamingStrategy to allow use of naming strategies for Enums #2667 (@EnumNaming)

[cowtowncoder]

Quick note: I haven't dig into why "RGBA" and '"RGBa"are translated by convention, but you can work around the issue by adding@JsonProperty` into one of conflicting values:

    enum ColorMode {
        RGB, RGBa,
        @JsonProperty("RGBA")
        RGBA
    }

[cowtowncoder]

Ok the problem is that names do translate both to rgba as per SNAKE_CASE_STRATEGY:

https://github.com/FasterXML/jackson-databind/blob/2.17/src/main/java/com/fasterxml/jackson/databind/PropertyNamingStrategies.java#L171

So this is a problem that was not detected until 2.15 (I think) -- behavior in 2.16 is as expected going forward.

In case where naming strategy converts value into conflicts, annotation is needed, or possible @EnumNaming override: however, adding:

@EnumNaming(EnumNamingStrategies.CamelCaseStrategy.class)

does not seem to help in this case (assuming it will not translate relevant values into separate ones)

[cowtowncoder]

Closing as wont-fix; solution is to apply annotation on one of conflicting values.

[cowtowncoder]

/cc @JooHyukKim you might be interested in this -- I had forgotten that the per-mapper default PropertyNamingStrategy is applied to Enum values.

[JooHyukKim]

Right, from users could feel awkward who are used to having Enums unaffected by PropertyNamingStrategy.
I should've thought this through wrt PropertyNameStrategy 🥲.

WRT, keeping backward compatibility either...

1. Keep the Enums behave as they are?
2. Or have EnumFeature as....

    // name yet TBD
    EnumFeature.APPLY_PROPERTY_NAMING_STRATEGY_TO_ENUMS

...such to keep the PropertyNamingStrategy away from Enums unless configured so.