On Wed, Sep 5, 2018 at 7:21 AM Alexey Tatarikov <[email protected]> wrote:
>
> Here is sample pojo:
>
> @Getter
> @Setter
> @Builder
> @NoArgsConstructor
> @AllArgsConstructor
> public class Pair<T, V> extends BaseObject implements Map.Entry<T, V> {
>
>     private T key;
>     private V value;
>
>     @Override
>     public V setValue(V value) {
>         this.value = value;
>         return value;
>     }
> }
>
>
> it is serialized as a Map.Entry:
>
> {"somekey":"value"}
>
> because we have isAssignableFrom check in BasicSerializerFactory
>
> https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/ser/BasicSerializerFactory.java#L383
>
> but it's not deserializing properly, because we have eq check in 
> BasicDeserializerFactory
>
> https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/deser/BasicDeserializerFactory.java#L1693
>
> is there any good reason why have different class checks in 
> BasicSerializerFactory and BasicDeserializerFactory?

Yes, the difference between the two is deliberate. Problem is that
whereas serialization using only interface (methods) of a super-type
-- like, say, `java.util.Map`, instead of specific
`java.util.LinkedHashMap` -- is often fine, same is not true for
deserialization: type substitution is not allowed.
Serialization and deserialization are not symmetric operations in many
ways. This is one manifestation.

In your case, for example, `Map.Entry` interface has suitable
accessors so that serializer can output something that is often
reasonable JSON output. But when deserializing, there is one basic
problem: `Map.Entry` has nothing usable for deserialization; no
setters, nor constructors (being abstract).
It is, however, possible to create a Map.Entry implementation -- but
that will not be assignable to arbitrary `Map.Entry` implementations.
This is why general-purpose deserializer can not be used, as is, for
custom implementations. This is different from `java.util.Map` and
`java.util.Collection`, for which it is often possible to use
general-purpose deserializer, as long as custom sub-type has
no-arguments constructor -- there are `put` and `add` methods to use.

So: as a general rule, registration of serializers via Modules
defaults to allowing type-and-subtypes, whereas deserializers usually
require exact (nominal) type match.

-+ 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 post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to