Discussed in https://github.com/FasterXML/jackson-databind/discussions/5218
import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.Test;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;
class EnumJsonPropertyTest {
static enum Color {
@JsonProperty
Red,
Blue,
Green
}
@Getter @Setter
@EqualsAndHashCode
static class Thing {
Color color;
}
@Test
void withEnumName() throws JsonProcessingException {
ObjectMapper mapper = new ObjectMapper();
String json = """
{"color": "Red"}
""";
Thing thing = mapper.readValue(json, Thing.class);
assertThat(thing.getColor()).isEqualTo(Color.Red);
}
@Test
void withBlank() throws JsonProcessingException {
ObjectMapper mapper = new ObjectMapper();
String json = """
{"color": ""}
""";
Thing thing = mapper.readValue(json, Thing.class);
assertThat(thing.getColor()).isEqualTo(Color.Red);
}
}
With jackson-databind 2.18.4, the test `withBlank()` fails and `withEnumName()` passes.
With 2.19.0/2.19.1, it's the other way around, `withEnumName()` fails and `withBlank()` passes.
Was this change intentional? According to the Javadoc of `@JsonProperty`, it seems like the behavior of 2.18.4 was actually incorrect, but I didn't see any mention of a bug like that in the release notes.
Comment From: cowtowncoder
@JooHyukKim I think this must be due to refactoring: "" for @JsonProperty
(and @JsonProperty("")
) should be no-op for enums, implicit name to be used as-is. This to be compatible with how @JsonProperty
works for POJO properties.
... I hope this was not meant as a fix tho?
Comment From: cowtowncoder
Oh. As per @erizzo-cfa 's comment
I just noticed this in the Javadocs (when using 2.19):
NOTE: for Enums, empty String is a valid value (and missing value is taken as empty String), unlike for regular properties, and does NOT mean "use default Enum name". (handling fixed in Jackson 2.19)
this is actually intentional. Sigh. I can see why this is tempting but in hindsight I should have pushed for identical handling. But it is now what it is in 2.19.0.