Describe the bug @JsonFormat does not work as expected when converting string to double and vice versa.
Version information 2.11.3
To Reproduce I have an entity with a double property. Challenge is to read an external API that sends the capacity value as string in German Format.
@JsonIgnoreProperties(ignoreUnknown = true)
data class Event(
@JsonProperty("NUMCapacity")
@JsonFormat(shape = Shape.STRING, locale = "de_DE", pattern = "#.#")
var capacity: Double,
Caused by: org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Cannot deserialize value of type `double` from String "158,1": not a valid Double value; nested exception is com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `double` from String "158,1": not a valid Double value
Expected behavior Expected behaviour is, when given the German locale, the comma is understood as the decimal separator.
Comment From: cowtowncoder
Makes sense that this could be used; as you have noticed, that neither explicit pattern not Locale-dependant default pattern is supported for "numbers-as-Strings" coercion case currently.
Should be support at least for float/Float, double/Double, BigDecimal (?). And probably integer counterparts too.
Comment From: Gaibhne
Is this issue abandoned ? I wanted to use Jackson for parsing numbers into BigDecimals too and stumbled over this same problem.
Comment From: MBurchard
Is this issue abandoned ? I wanted to use Jackson for parsing numbers into BigDecimals too and stumbled over this same problem.
As you see, nothing happens in more than a year. So It has at least no priority.
Comment From: cowtowncoder
In OSS projects it all comes down to someone having time and itch to work on things -- I don't think anyone has worked or is working on this, no. Filing issues is not an order form for getting free stuff; it can be used to suggest but fundamentally someone somewhere has to do the work and there's no shortage of various things to fix, add, change.
So: Contributions welcome! This looks like something that would be relatively easy to make progress on. And if you want a feature, you might have the itch to make it happen.
Comment From: emiatej9
Searching code related to this issue, I found below lines in deserializeAndSet method:
https://github.com/FasterXML/jackson-databind/blob/ada34dcf6676aa5c5869791c23143a65a7bf56c2/src/main/java/com/fasterxml/jackson/databind/deser/impl/FieldProperty.java#L135-L140
In line 138 _valueDeserializer have reference of static class DoubleDeserializer in NumberDeserializers. I think the annotations the _field property is holding should be passed to DoubleDeserializer#deserialize(p, ctxt) at this point so as to exploit locale and pattern before parsing the given text.
https://github.com/FasterXML/jackson-databind/blob/ada34dcf6676aa5c5869791c23143a65a7bf56c2/src/main/java/com/fasterxml/jackson/databind/deser/impl/FieldProperty.java#L31-L36
However, It seems very difficult to modify parameters of deserialize(Jsonparser p, DeserializationContext ctxt) method which is inherited from JsonDeserialize class.
Could you give me some hints or guides to fix this issue?
Comment From: cowtowncoder
@emiatej9 Typically all handling of format annotations should be done during construction or contextualization phases and specifically should never be passed (and rarely if ever used) accessed during actual deserialization calls.
Contextualization refers to handling in method createContextual(), which is called after construction but before any actual use for deserialization. It will be passed BeanProperty through which annotations (property and class annotations) are accessible.
You don't need to check FieldProperty methods: this is not the place handling should occur (since these are deserializer-independent entities).
Instead, createContextual() method -- you may want to see how other standard deserializers use it -- usually checks for various configuration settings, annotations, and so on, and then creates (and returns) a differently configured instance as necessary.
Comment From: krish2kdev
@cowtowncoder can i work on this issue?
Comment From: JooHyukKim
Read this issue and PR https://github.com/FasterXML/jackson-databind/pull/3485 thoroughly and you will find out probability of resolving this issue is very low @krish2kdev
Comment From: cowtowncoder
Yeah... I am not sure if I wanted such feature or not. Seems like something for which custom serializer/deserializer combination might make most sense. Things just get quite complicated.