Object class level custom deserializer not utilized when Object is Map key

[mluckam]

When an Object utilizes a class level custom deserialier @JsonDeserialize(using = XXX.class) or class level custom serializer @JsonSerialize(using = XXX.class), these are not utilized when deserializing/serializing the key of a map.

Example project linked shows use case with the class com.google.cloud.tools.jib.api.DescriptorDigest. Class level deserializer is utilized for class DescriptorDigest when deserialized directly or as a Set<DescriptorDigest>. The class level deserializer is not utilized when DescriptorDigest is a key or value in a map. Instead the constructor is called via MapDeserializer and StdKeyDeserializer.StringCtorKeyDeserializer. Note the same is true for serialization.

Is this the expected behavior? Collections are able to infer the type and utilize class level custom deserializers/serializers, so I found it odd that Map was unable to do this without an explicit @JsonDeserialize(keyUsing = <KeyDeserializer>.class), see code.

[cowtowncoder]

Key serializer/deserializer settings are not same as value (de)serializer: there are separate keyUsing methods because JSON Object keys are always Strings (and are exposed during different JsonToken).
This is different from Collections (JSON Arrays) where elements/contents can be of any legal value type.

So this distinction exists due to limitations on legal value types. In hindsight it might have been good idea to require JsonSerializer / JsonDeserializer expose methods for from/to-String (de)serialization, so one could register just one set of handlers.
But as things are, Key serializer/deserializer are distinct from regular ("value") (de)serializer.

So, in short: yes, this is expected: registering value serializer/deserializer does not register handler for Map key serialization/deserialization. Separate handlers are needed.

[threadedblue]

I have a similar problem/question.

I have a set of custom deserializers that I register. They work nicely until there is an array in the JSON.

I have two string values to contend with: 1) java.lang.String and 2) org.hl7.fhir.String. They are incompatible. I have a custom serializer and deserializer to handle the conversation and they both work. When org.hl7.fhir.String is encountered in the object graph, the custom deserializer is called. But when the JSON has an array of string values and my object has an EList (derived from java.util.List) of those values (i.e. org.hl7.fhir.String) the custom deserializer is never called and an error is thrown that complains about the end of array.

Q: What is going on here? Why does Jackson not call a custom when inside a list/array?
Is there any way to get Jackson to handle this? I tried writing a workaround, but my effort soon turned into a death march down the proverbial rabbit hole.

Thanks in advance

[cowtowncoder]

@threadedblue Custom (de)serializers work with Arrays (and Lists, Collections), but it depends (esp. in case of deserializers) on declared type and to some degree on how custom (de)serializer is registered.

I am not sure I fully understand your expected usage, so it'd be worth filing an issue with actual reproduction: expected use case that is not working the way you think it should.