Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serialization of scala.collection.immutable.ListMap fails in 2.9.x #2111

Open
mosesn opened this issue Aug 15, 2018 · 9 comments
Open

serialization of scala.collection.immutable.ListMap fails in 2.9.x #2111

mosesn opened this issue Aug 15, 2018 · 9 comments

Comments

@mosesn
Copy link

mosesn commented Aug 15, 2018

This might be related to #2080, not 100% sure. I'm trying to upgrade from 2.8.3 to 2.9.6, and I'm getting a new exception in some of our tests,

Failed to specialize base type 
scala.collection.immutable.ListMap<com.twitter....LengthBucket,java.lang.Object> as 
scala.collection.immutable.ListMap$Node, problem: Type parameter #1/2 differs; 
can not specialize com.twitter...LengthBucket with java.lang.Object

I think there's a bug in the way that the ListMap serializer is implemented in jackson-module-scala, but it used to work, and #2080 pointed out that TypeHandlers shouldn't need to know about these details, so I hope this can be fixed in jackson-databind. In the mean time, any idea how we can work around this issue?

@cowtowncoder
Copy link
Member

Unfortunately I do not know much about Scala, to know why generic type mapping fails.
If there was a reproduction that replicated type hierarchy of Scala standard containers but in Java (just for purpose of replicating underlying issue), I could have a look. There have been couple of edge cases on Java side too, where tightening of type assignment checks (when resolving generic types) has caused issues.
One problem, in particular, is that such compatibility checks probably should be more relaxed or ignored during serialization (and stricter on deserialization), but as things are type resolution itself has no knowledge of context -- its rules are same regardless of operation.

@mosesn
Copy link
Author

mosesn commented Sep 2, 2018

For what it's worth, the MapperFeature.USE_STATIC_TYPING workaround works for this too.

@cowtowncoder
Copy link
Member

@mosesn Thank you for sharing that. Workaround makes sense since STATIC_TYPING would force use of declared type for properties, without attempts to use (usually) more specific runtime type on serialization.

@Felk
Copy link

Felk commented Mar 13, 2019

The issue you mentioned (#2080) has been resolved in 2.9.8. You could give it a shot without the workaround now

@dejanlokar1
Copy link

It does not appear to work with 2.9.9. I reproduced it here: https://github.com/dejanlokar1/serialization_problem

@cowtowncoder
Copy link
Member

@dejanlokar1 Is your comment related to this issue, or one referenced (#2080)? If latter, and is distinct from this one, could you please file a new issue for it (I prefer that over re-opening issues in cases where fix for issue has been included in release notes).

@dejanlokar1
Copy link

@cowtowncoder it appears related to #2080. ListMap can be serialized, but a class with a property of type ListMap fails to serialize (test case).

Last working version is 2.9.2. I can make another issue, however, this looks like the same problem.

@cowtowncoder
Copy link
Member

@dejanlokar1 I think it's best to file a new issue with description of remaining problem and link to older one (with mention it is probably related). And adding link to reproduction you mentioned.
It is possible that earlier fix has solved part of the problem; and it's not uncommon that problems that affect root value (one directly passed for serialization) are bit different than those affecting property values.

@dejanlokar1
Copy link

@cowtowncoder thank you! I opened a new issue #2422.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants