jackson-datatypes-collections
jackson-datatypes-collections copied to clipboard
(guava) Better multiset serialization / deserialization
(moved from https://github.com/FasterXML/jackson-datatype-guava/issues/51 by @devinrsmith)
Currently, multisets' serialization size is proportional to Multiset.size() as opposed to Multiset.entrySet().size().
For example, if I have do Multiset<String>.setCount("my_key", 1000), "my_key" is repeated 1000 times in the output. It would be much more appropriate if it behaved liked Map<String, Integer>.
I'm not familiar w/ the intricacies of jackson serialization / deserialization. I'd be pretty surprised if there is widespread use of serializing Multisets (using the existing jackson library)... I would have guessed a lot of other people would be bringing up this exact issue if they were using it. Does jackson ever create hard-breaks in backwards compatibility?
Typically the way changes like this are handled is by introducing a new on/off Feature (for module or component) which defaults to old behavior, and can be changed to support new handling. But there are limited number of cases where we have just changed the setting, if we really think there is very low risk of problems.
This might be something to bring up on dev mailing list, esp. since there may be multiple ways data could be structured.
But I can definitely see why change would be useful here; it's just a question of how to best improve the situation.
Second this issue. Just come across a production problem where the succinct serialization would be immensely useful. By reading these two posts and realizing jackson does not currently support succinct serialization, I have to move back to Map<T, Long>.
PRs welcome.