Allow case insensitive deserialization of String value into `boolean`/`Boolean` (esp for Excel)

[pjungermann]

At the moment, com.fasterxml.jackson.databind.deser.std.NumberDeserializers.BooleanDeserializer#_parseBoolean support only "true" and "True" (and the same for false) but fails for values like "TRUE" It would be great to do the matching case insensitive out of the box (similar to how java.lang.Boolean#parseBoolean checks for true)

[cowtowncoder]

Hmmh. Actually... it might be possible to enable this by making use of existing

@JsonFormat(with={ JsonFormat.Feature.ACCEPT_CASE_INSENSITIVE_PROPERTIES })

on property, or as global default (for types java.lang.Boolean and Boolean.TYPE, that is; wrapper and primitive).

I am mostly thinking of API here because I know that there are users who absolutely dislike allowing of non-standard variants (it is possible to disable coercion with MapperFeature.ALLOW_COERCION_OF_SCALARS, to prevent String-to-boolean; but that's separate of case-sensitivity).

[bobbylight]

I just ran into this today. My app allows exporting existing data to CSV, for the user to edit and re-upload with updates. When editing the exported CSV in Excel, Excel helpfully converts true and false to TRUE and FALSE, respectively, which breaks on re-importing as described in this feature request.

[cowtowncoder]

@bobbylight Thank you for the additional datapoint. This makes (more) sense. I wonder if this is something that could be further handled or helped at CSV decoder level... the challenge here is that in many cases decoder does not do additional type coercion. But at the same time, for some other formats such coercion might not be useful.

One other idea I realized is that @JsonFormat has (in 2.9) property lenient, which could also work here, through configuration similar to case-sensitivity. But maybe explicit one is still better.

[bobbylight]

Configuration of Jackson is still a little voodoo to me, so I definitely trust your judgment on how best to address this. 😀

But in the mean time, what is the simplest workaround for my project? Do I have to write a deserializer for my pojo type containing boolean fields, or is there an easier way?

[cowtowncoder]

Yes, custom deserializer is probably the way to go at this point. Or, if you have control over POJO in question, setter that either takes String (if that's what value looks like -- this is true for CSV), or Object if it could come as multiple types (and then check if String or Boolean is passed). Latter is actually less work and in many ways superior, but needs to be done for every property.

[remal]

I've sent a PR for the issue: #2132