Thank you very much Tatu for your response. I did as suggested and filed a bug-report: https://github.com/FasterXML/jackson-databind/issues/3334
On Tuesday, November 23, 2021 at 9:07:18 PM UTC+1 [email protected] wrote: > On Tue, Nov 23, 2021 at 10:35 AM Steffen Springer <[email protected]> > wrote: > >> Used version: *jackson 2.13.0* >> >> In general writing and reading of Double.NaN works fine. However, if I >> want to write a class like this >> >> public class SimpleClass { private Map<String, Double> map;} >> >> and the map contains a Double.NaN value, it gets tricky. >> >> With >> >> ObjectMapper.DefaultTyping.NON_FINAL) >> >> it works, with >> >> ObjectMapper.DefaultTyping.EVERYTHING) >> >> a json is written, which cannot be read. Reading fails with an Exception >> >> Exception in thread "main" >> com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot >> deserialize value of type `java.lang.Double` from Array value (token >> `JsonToken.START_ARRAY`) at [Source: (String)"[ >> "de.epoq.rs.sai.utils.JacksonNaNMapValueExample$SimpleClass", { "map" : [ >> "java.util.HashMap", { "A" : 1.0, "B" : [ "java.lang.Double", "NaN" ], "C" >> : [ "java.lang.Double", "Infinity" ] } ] } ]"; line: 4, column: 11] >> (through reference chain: >> de.epoq.rs.sai.utils.JacksonNaNMapValueExample$SimpleClass["map"]->java.util.HashMap["B"]) >> >> at >> com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:59) >> >> at >> com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1741) >> >> >> Please see the attached file for a full working example. >> >> >> *My question is:* >> >> Why is this happening ? Why is the map within the class is treated >> differently now ? >> >> > Hi Steffen! I would file an issue against jackson-databind, with a > reproduction, ideally unit test. > It sounds like incorrect handling; I don't think it is intentional. > > As to the cause this is probably related to the fact that Double is one of > a small set of "natural" types (along > with String, Boolean and Long), for which additional Type Id is never > added. This is an old and somewhat unfortunate > optimization, used to reduce Type Id overhead specifically for String > values. > This probably leads to using a different deserializer in the Default > Typing case or something which somehow does not > take into account NaNs. > > With a reproduction it may be possible to avoid the issue. > > -+ Tatu +- > > > > > -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/934e673d-6bc5-484e-8787-5df5b80f9116n%40googlegroups.com.
