Upgrading Guava baseline dependency for Jackson 2.10, from Guava 18.0 to.... ?

[Tatu Saloranta]

Quick note: as per:

https://github.com/FasterXML/jackson-datatypes-collections/issues/23

there is desire to

(a) Extend range of allowed Guava versions to include 23, and
(b) Update minimum version supported from 18 to something later

both for Jackson 3.x (less of a concern since it'll be out at earliest
by end of 2018), and
for 2.10 (more concern).

I know Guava has traditionally been quite aggressive in deprecating
and removing functionality so I hesitate to simply change version deps
and hope for the best.
But at the same time we do need to try to balance needs of users
relying on newer versions with those of stability.

So.... if anyone has time and interest to investigate what kind of
dependency upgrade would be good trade-off, that would be good. :)

For what it is worth, Jackson 3.x currently upgrades dependency from
18.0 to 20.0, so perhaps that would be the starting hypothesis -- we
would try to make Guava module of Jackson 2.10 to work with Guava
versions [20.0 ... 23.0]?

-+ Tatu +-

[Tatu Saloranta]

Fast-forward to Coronarific 2020, situation is such that Jackson 2.10
and 2.11 require Guava v20 as baseline.
They may or may not work with older versions (does anyone have
information? I can probably test this relatively easily),
maybe down to v18 or even v16, but guaranteed for v20 wrt automated testing.
Jackson 3.0 uses baseline of v25 but since that is not about to be
released in near future, that is probably less relevant.

Baseline for Jackson 2.12 is not yet determined. I could leave it at
v20, but there is a new interesting PR:

https://github.com/FasterXML/jackson-datatypes-collections/pull/69

which seems to require v23. Now, based on my work outside of Jackson I
know that Guava version dependencies
are tricky due to its wide usage and Guava maintainers aggressive
deprecation of old features: libraries tend to work
with some range of Guava versions, and in case of Jackson we need to
balance needs of those using latest versions
(which typically work ok with Jackson, fortunately) with those who
have dependencies to things that only work with
older Guava versions.

I think 2 main options would be to:

1. Keep v20 minimum
2. Upgrade minimum to v23 (which v25 is bit more widely used it seems
there is some value in conservative updates)

Does anyone know of practical consequences of version upgrades; any
well-known limitations that might favor use of
specific Guava version (as I recall, v19/v20 tended to be reasonably
good versions wrt compatibility for things that need
older Guava)?
Or have opinions, suggestions?

-+ Tatu +-

[Jochen Schalanda]

Hi,

without going into too many details, the Guava team acknowledged the problems coming from Guava breaking backward-compatibility regularly and started to be more strict and thoughtful about evolving the library.

Starting with Guava 21.0, all releases should be backward-compatible down to that version:

https://github.com/google/guava/blob/master/README.md#important-warnings

• APIs without @Beta will remain binary-compatible for the indefinite future. (Previously, we sometimes removed such APIs after a deprecation period. The last release to remove non-@Beta APIs was Guava 21.0.) Even @Deprecated APIs will remain (again, unless they are @Beta). We have no plans to start removing things again, but officially, we're leaving our options open in case of surprises (like, say, a serious security problem).

See also: https://github.com/google/guava/wiki/ReleasePolicy

So my suggestion is raising the minimum version to at least Guava 21.0 which is most likely to be "forward-compatible" with new Guava versions.

Cheers,

Jochen

-- 
You received this message because you are subscribed to the Google Groups "jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10jESmj0hPryNJ9O2-%2By8LQngnSHMoTO3Do1h3kSe8fUGw%40mail.gmail.com.

[Tatu Saloranta]

On Wed, Jul 29, 2020 at 11:37 PM Jochen Schalanda <joc...@schalanda.name> wrote:
>
> Hi,
>
> without going into too many details, the Guava team acknowledged the problems coming from Guava breaking backward-compatibility regularly and started to be more strict and thoughtful about evolving the library.
>
> Starting with Guava 21.0, all releases should be backward-compatible down to that version:
>
> https://github.com/google/guava/blob/master/README.md#important-warnings
>
> APIs without @Beta will remain binary-compatible for the indefinite future. (Previously, we sometimes removed such APIs after a deprecation period. The last release to remove non-@Beta APIs was Guava 21.0.) Even @Deprecated APIs will remain (again, unless they are @Beta). We have no plans to start removing things again, but officially, we're leaving our options open in case of surprises (like, say, a serious security problem).
>
> See also: https://github.com/google/guava/wiki/ReleasePolicy
>
> So my suggestion is raising the minimum version to at least Guava 21.0 which is most likely to be "forward-compatible" with new Guava versions.

Good point, thank you for sharing. I think I have heard about this
before but did not remember the cut-off point.

I guess the other thing to consider really is that there needs to be
specific need to increase the baseline requirement
(which itself is separate from the question of default Guava version
that pom.xml specifies).
Increasing baseline to 21.0 for Jackson 2.12.0 makes sense so I will
just do that, then, but will still need to consider
whether to accept PR contributed for inclusion, as that requires
version 23.x at least (although I probably should verify
that is enough; there may be something else referring to even newer version).

Theoretically it might also be possible to try dynamic loading for
some aspects; this could be another route....
So, to compile and build, newer version is needed, but to make use of
some of functionality, either:

1. Make user add a component explicitly (simple, reliable, but
slightly more work), or
2. Make module use dynamic class loading (more complex, new error
modes, but ideally user need not do anything).

I am sort of thinking that maybe for 2.12 option (1) would make sense...

-+ Tatu +-

> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/8FB6BF52-5DB0-4735-9049-AB5AC69AFF15%40schalanda.name.