Remove Guava dependency from protobuf-util

[guw]

The OSGi version imports for Guava are very narrow. For example, they tightly couple the utils bundle to just one particular Guava release and prevent it from running with latests.

I would recommend setting only a minimum version for Guava but no upper bound.

It could be achieved by adding the following attribute to util_bundle:

    bundle_additional_imports = ["com.google.common.*;version=\"${@}\""],

[laeubi]

I would recommend setting only a minimum version for Guava but no upper bound.

This is really bad, please see https://docs.osgi.org/whitepaper/semantic-versioning/ for proper choice of version bounds. An unbounded import is the best way to wait for bad things to happen.

In general I think guava is one of the libraries that are just to badly shaped (combined with its unclear versioning / compatibility rules) to be used as a real dependency and if one really aims for best interoperability conditional package might be a better choice here: https://bnd.bndtools.org/instructions/conditionalpackage.html

[esrauchg]

The high level state here is that we avoid a guava dep from the protobuf package but the protobuf-util package does have deps (the biggest ones being Guava and GSON).

@laeubi makes a good point for why we don't want to declare blanket upper bounds as a matter of semver principle, and I think we're going to leave it that way for now.

Note that Guava does make breaking changes but also wouldn't break widely used APIs (nor ABI break them) and is also somewhat conservative about their definition of breaking changes, which means it bumps their major version in some cases where other common libraries would just be a bit fast-and-loose and call it a minor version. The surface area of Guava that protobuf-util is relatively limited, and Guava is not going to eg break the ImmutableSet.of() methods in any future release.

Our broad intent is that protobuf-util to eventually move off of Guava dep, which is something that is slowly happening (including moving onto something java.lang.Math functions where possible), we don't expose it on the API surface so we can drop the Guava dep at some future date without it being a breaking change. Unfortunately a few of the simple things that we do use from Guava are somewhat sprawling in internal implementation, so simply vendoring them with a new package as package-private would be a bit heavy today, so realistically the status quo is probably going to be this way for a bit unless there's a better story.

Some of the things we use have JDK equivalents added but only in Java9+ (lke List.of()) which unfortunately means we can't use them yet as we still support Java 8.

[guw]

we don't want to declare blanket upper bounds as a matter of semver principle

@esrauchg I would like to highlight that this decision is flawed because Guava does not follow the semver principle on a per package level. It applies it globally to anything happening within Guava.

Thus, the strict upper bound limits really hurt adopters. This is another example of perfect being the enemy of good. All I ask for is being pragmatic. Removing the upper bound limit simplifies work for (mostly involuntary) protobuf-util consumers a lot. It's not perfect from OSGi standpoint but neither is Guava.

[esrauchg]

I'll reopen the issue, but the fix to the issue will be "remove guava dep from protobuf-util" rather than "change the OSGi version range".

I will try to see if I can speed up getting that over the line.

I understand the pain point, but the root problem is really more of a fundamental Java ecosystem painpoint where it is the norm to have sprawling deps, all of those libraries are are only validated to work against some specific versions, those versions are often not overlapping, and somehow users still have to figure out how to make their diamond dependencies work out. The OSGi is declaring the version that Protobuf has validated, which I believe isn't semver pedantry but 'correct' and idiomatic.