You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this should be filed as a bug or a feature request, since the "expected" behavior is mostly left to interpretation, but I went with a bug report in the end. Let me know if that makes sense.
Describe the bug
Deserializing an enum field that is marked for case-insensitive deserialization does not work if the source value happens to be shaped as the string representation of a number, whereas the same value will be deserialized properly if case-insensitive deserialization is disabled.
Version information 2.12.4
To Reproduce
If you have a way to reproduce this with:
class MyClass {
@JsonFormat(with = JsonFormat.Feature.ACCEPT_CASE_INSENSITIVE_PROPERTIES)
public MyEnum enumValue;
}
Json input
ACCEPT_CASE_INSENSITIVE_PROPERTIES: disabled
ACCEPT_CASE_INSENSITIVE_PROPERTIES: enabled
{ "enumValue": "FIRST_MEMBER" }
✅
✅
{ "enumValue": "first_member" }
❌
✅
{ "enumValue": 0 }
✅
✅
{ "enumValue": "0" }
✅
❌ 👈
Both failures (❌) are the same:
com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `MyClass` from String <X> not one of the values accepted for Enum class: ...
Expected behavior
I would expect the case annotated with 👈 in the table above to successfully deserialize the value. It seems as if the reason why this is not the case for now is that the conditional branches branches that handle the case-insensitive parsing and the number-based enum parsing are mutually exclusive:
"value looks like quoted Enum index, but `MapperFeature.ALLOW_COERCION_OF_SCALARS` prevents use"
);
}
if (index >= 0 && index < _enumsByIndex.length) {
return_enumsByIndex[index];
}
} catch (NumberFormatExceptione) {
// fine, ignore, was not an integer
}
}
}
Not sure if this is by-design or if there is a historical precedent that lead to this, but I don't see why the deserialization process couldn't rely on attempting the number-based parsing in the case where _caseInsensitive is true and the subsequent lookup failed to return any results.
The text was updated successfully, but these errors were encountered:
From description I think you are right that this SHOULD work and is just an unfortunate implementation detail that it doesn't. I hope someone has time to look into this; I'd be happy to help with a PR, but do not have time right now to look into providing one myself (but may have in future, of course).
Thank you @pgrefviau for reporting this, adding reproductions.
Not sure if this should be filed as a bug or a feature request, since the "expected" behavior is mostly left to interpretation, but I went with a bug report in the end. Let me know if that makes sense.
Describe the bug
Deserializing an enum field that is marked for case-insensitive deserialization does not work if the source value happens to be shaped as the string representation of a number, whereas the same value will be deserialized properly if case-insensitive deserialization is disabled.
Version information
2.12.4
To Reproduce
If you have a way to reproduce this with:
ACCEPT_CASE_INSENSITIVE_PROPERTIES: disabled
ACCEPT_CASE_INSENSITIVE_PROPERTIES: enabled
{ "enumValue": "FIRST_MEMBER" }
{ "enumValue": "first_member" }
{ "enumValue": 0 }
{ "enumValue": "0" }
Both failures (❌) are the same:
Expected behavior
I would expect the case annotated with 👈 in the table above to successfully deserialize the value. It seems as if the reason why this is not the case for now is that the conditional branches branches that handle the case-insensitive parsing and the number-based enum parsing are mutually exclusive:
jackson-databind/src/main/java/com/fasterxml/jackson/databind/deser/std/EnumDeserializer.java
Lines 306 to 330 in f5a84a5
Not sure if this is by-design or if there is a historical precedent that lead to this, but I don't see why the deserialization process couldn't rely on attempting the number-based parsing in the case where
_caseInsensitive
is true and the subsequent lookup failed to return any results.The text was updated successfully, but these errors were encountered: