Type parameters are checked for equality while isAssignableFrom expected

[frankfiedler]

I have a problem with the serialization of a class of mine with an acutal version of the jackson serialization. The last version working with my code is the 2.8.10 as far as I know.
The problem I see is that the serialization checks in file jackson-databind-2.9.5-sources.jar!/com/fasterxml/jackson/databind/type/TypeFactory.java:474 while I would expect the check to make sure that the field-type is only assignable-from the concrete instance of a field.

I prepared a testcase which I attach to this report.

testcase-plugin-serialization.zip

The entry point for my testcase is the class called MyTest. There you find a function

• problem() : producing the problem
• workaround() : working around the problem by doing the serialization in the problematic class manually

In the example the ProblematicPlugin has a value type named ValueAndState which implements Serializable. As the serializer checks for Serializable == ValueAndState the check fails while I think the check should do field.isAssignableFrom(valueAndStateInstance).

The class WorkaroundPlugin contains my current work around, doing the serialization of the members myself and just bypassing the check in the class itself.

I would like to ask for a change in the serializer checking for isAssignableFrom(..).

Any feedback and questions welcome.

[cowtowncoder]

I am not 100% sure I fully understand your problem here, but keep in mind that TypeFactory is not responsible for enforcing assignment validity -- all it needs to do is to ensure that type resolution of generic types works as expected, and then resolved JavaType is used by other functionality such as JsonSerializers to determine validity. Exception may be triggered by TypeFactory, still, for some cases where serializers or deserializers try to combine static type declaration information with runtime type information -- this is sanity checking that is needed to avoid incorrect usage by custom code (to catch bugs in case caller passes incompatible arguments).

Having said that, there have been some issues, however, in which some cases of types that should not cause problems for serialization (but would for deserialization) being problematic. So it is possible you are hitting one such case. A few have been fixed for 2.9.x, caused by stricter type assignment verification during resolution, compared to 2.8.x.

I hope to look into the test case in near future, but right now I am quite overworked so that may take a while.

[frankfiedler]

Thanks for looking into this. I understand what the TypeFactory is being used for. My point is that it is to strict checking for matching types. In my example the base class of the serialized object has a generics parameter of the type Serializable. The specific object to be serialized has a Type inheriting/extending Serializable. The TypeFactory now checkes for Serializable == SpecialClassImplementingSerializable which of course is not true. From my point of view it would be better to check BaseClass.isAssignableFrom(SpecialClassImplementingSerializable). The BaseClass is Serializable in this case. Am Fr., 12. Okt. 2018 um 00:08 Uhr schrieb Tatu Saloranta < notifications@github.com>:

…

I am not 100% sure I fully understand your problem here, but keep in mind that TypeFactory is not responsible for enforcing assignment validity -- all it needs to do is to ensure that type resolution of generic types works as expected, and then resolved JavaType is used by other functionality such as JsonSerializers to determine validity. Exception may be triggered by TypeFactory, still, for some cases where serializers or deserializers try to combine static type declaration information with runtime type information -- this is sanity checking that is needed to avoid incorrect usage by custom code (to catch bugs in case caller passes incompatible arguments). Having said that, there have been some issues, however, in which some cases of types that should not cause problems for serialization (but would for deserialization) being problematic. So it is possible you are hitting one such case. A few have been fixed for 2.9.x, caused by stricter type assignment verification during resolution, compared to 2.8.x. I hope to look into the test case in near future, but right now I am quite overworked so that may take a while. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AqBhbs0TusNn0dcEKEp91GBzYc9wUulUks5uj8E-gaJpZM4XX2q1> .

--

-- Frank Fiedler

[cowtowncoder]

@frankfiedler I finally had time to look again into this, and I see what you mean. I will relax the check a bit to allow assignment compatibility for interfaces as type parameters (and this may not be the last change but works here).

Thank you for submitting the issue; will be fixed in 2.9.8.

[frankfiedler]

Thank you very much. I really appreciate your support! Am Di., 20. Nov. 2018 um 07:21 Uhr schrieb Tatu Saloranta < notifications@github.com>:

…

Closed #2155 <#2155> via dd6d460 <dd6d460> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AqBhbn67qkwSrawWroNqQU4Z8mwmt0M0ks5uw595gaJpZM4XX2q1> .

--

-- Frank Fiedler

[cowtowncoder]

@frankfiedler Thank you for persisting on this and helping me improve handling!