jackson-datatypes-collections
jackson-datatypes-collections copied to clipboard
FasterXML
Support for fastutil collections
It would be nice to support fastutil collection The previous discussion: https://markmail.org/message/anwbtpgbvwh4ox4v#query:+page:1+mid:xqwwbpgh2ul46nst+state:results
I could do this by copy pasting https://github.com/FasterXML/jackson-datatypes-collections/tree/master/hppc and some parts from https://github.com/FasterXML/jackson-datatypes-collections/tree/master/eclipse-collections very literally, but maybe it's time to do some refactoring and introduce basic primitive collection serialization types for all primitive collection libraries, which specific libraries could subclass trivially?
First of all, +1 for fastutil datatype.
As to shareable code, I am bit ambivalent on that, mostly regarding technical details of how to make it work in a way that does not add fragility.
So, I am +1 for being able to reuse up-to-date components, in itself. But I am bit worried about keeping things in-sync, and not adding to challenges of inter-component dependencies.
I have limited reuse/adoption of base classes from jackson-databind in some cases, to (for example) wait 1 minor version before making datatype use newly added base types (to retain some level of compability between "adjacent" minor releases (that is, making it more likely that some combinations of 'close enough' versions of databind, datatype, still work even if not guaranteed).
So: I think that maybe it could start with clean up of one of collections datatypes, refactoring, creating suggested base types, but not yet extracting these in first version, but cut'n pasting copies (in different packages)? This is how base ReferenceType serializer, deserializer (for Java 8 / Guava / Scala Optional, JDK AtomicReference) was implemented.
Another thing to consider is that alternatively base classes could be formally added in 3.0, since anything 3.x version would start with fresh baseline (i.e. there is no need to worry about backwards compatibility for that one particular version).
Finally, there is of course little bit of base class functionality already in 2.x (AsArraySerializer, ContainerSerializer etc, I think). This could perhaps serve as some sort of basis.
Anyway: I think I would probably start by making new datatype modular, with base classes that would seem like they could work for most other container types (for Guava, HPPC etc). Then see if copying base classes would work: release one minor version with such cut-pasted versions.
And if/when this works, include shared base classes either in jackson-databind (if somewhat limited number of types -- judgment call), or in new shared component.
... come to think of that, if a separate component used, could even consider shading code in, instead of adding dependency. That would alleviate version compatibility concerns, as long as care is taken never to expose those types via API (since they will all be repackaged under different Java packages via shading).
I was thinking about extracting yet another separate package "jackson-databind-primitive-collections-base", on which hppc, pCollections, eclipse-collections and fastutil could depend, rather than pulling that base classes into jackson-databind itself. Maybe if they are in a separate package, compatibility standard could be eased a bit.
That works, either as separate artifact, or by maybe shading common parts (I think having single source gets most of benefits) into artifacts.
I don't think anyone is working on this at the moment. The infrastructure is there with primitive-collections-base, but someone would have to implement the fastutil parts. The eclipse-collections module is a good template, so feel free to try your hand
