Add support for Guava ImmutableIntArray / ImmutableDoubleArray (2.22)

[kilink]

Add serde support for ImmutableIntArray and ImmutableDoubleArray.

Note that for simplicity, the deserializers currently delegate to the implementations in PrimitiveArrayDeserializers, passing the deserialize primitive arrays to the respective copyOf factory methods. The benefit is that all of the various edge cases of reading ints / doubles is handled already in those implementations. The downside is that we make an extra copy of the array when we pass it to the copyOf method, but at least there is no waste in the array sizing in this case.

[yawkat]

LGTM, but have you already signed the CLA?

[cowtowncoder]

Ah yes -- happy to help get this reviewed, but before merging will need CLA (if not already sent earlier; only needs to be done once before the first contribution). It's this:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

and the usual way is to print, fill & sign, scan/photo, email to cla at fasterxml dot com.
ONce this is done I can proceed with merging (assuming review goes fine etc).

[kilink]

Sure, I can get the CLA signed; but also I realized that ImmutableIntArray / ImmutableDoubleArray were added in Guava 22.0, so this change cannot really be merged anyway if the minimum supported Guava version is still 20. For some reason I thought these classes had been around much longer.

[cowtowncoder]

Ok, one immediate problem tho: looks like our CI is still assuming min Guava level of 20, and ImmutableIntArray was added in Guava 22 (as per Javadocs).
Note that this is different from default dependency indicated, Guava 25.

So: do we want to bump minimum supported Guava to 22 for Jackson 2.18?
I don't have strong opinion here, but will need to file separate issue to increase that, if agreed.

EDIT: filed #158

[cowtowncoder]

@kilink One possibility: postpone Guava baseline upgrade to Jackson 2.19, merge this in after 2.18.0 released? This gives us more time.

[kilink]

@kilink One possibility: postpone Guava baseline upgrade to Jackson 2.19, merge this in after 2.18.0 released? This gives us more time.

I'm fine with that. Not really an urgent need for this, I just saw it as a gap. I can continue just using the custom serializers / deserializers directly for now.

[cowtowncoder]

Would like to proceed with this, wrt merging into 2.19, but need 2 things:

1. PR needs to re-based (or re-created against 2.19)
2. CLA

with that, I'd be happy to merge this!

[cowtowncoder]

Now that #158 complete, baseline not a blocker. But looks like this pr is not mergeable as-is...

[kilink]

@cowtowncoder sorry for the delay, I've found a printer finally and signed the CLA. Is this change still needed? If so, I can rebase it.

I noticed that 3.x already has support for these types, however the implementations look like they allocate and box unnecessarily, and may have a bug (doesn't write anything for empty arrays). Anyway I am fine with rebasing this PR if you'd still want it in 2.x, or I can just close it.

[cowtowncoder]

@kilink I'd be happy to get 2.x (for 2.22) version. And maybe could replace 3.x implementation with improvements you mention?

[kilink]

@cowtowncoder okay, I've rebased onto 2.x and updated the PR to point to that. I also added support for WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED and added tests for that as well as UNWRAP_SINGLE_VALUE_ARRAYS.

[cowtowncoder]

Looks good; couple of small suggestions (I might apply changes too if need be).

[cowtowncoder]

LGTM!

[cowtowncoder]

@kilink Will merge this --as a follow-up, it would be great to get get long variants too, if you have time & interest (if not that's fine, this is already good!).

EDIT: realized how straight-forward this is so went ahead and did #213 . So no need for extra work for long[].

[cowtowncoder]

Ok, I managed to merge this into 3.x as well, although it's bit of hybrid for now.

I think I'll try to follow-up here for long/Long to unify things bit more.

[kilink]

@kilink Will merge this --as a follow-up, it would be great to get get long variants too, if you have time & interest (if not that's fine, this is already good!).

EDIT: realized how straight-forward this is so went ahead and did #213 . So no need for extra work for long[].

Thanks! Not sure how I missed the long variant...