jackson-coreutils
jackson-coreutils copied to clipboard
Transient dependency on Guava 16 prohibits higher-level code moving to Guava 21
The crash one sees when putting Guava 21 on the classpath is the following:
java.lang.NoSuchMethodError: com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at com.github.fge.jackson.JsonLoader.fromResource(JsonLoader.java:83
....
Guava 21 is appealing because it adds a number of very useful utilities for working with Java 8. However in this release, they have (after a period of planned deprecation) removed methods from their Objects
class (due to Java 8 containing an Objects
class).
I understand jackson-coreutils
may wish to retain support for Java 6. Fortunately, Guava planned ahead and there is a window of cross-over:
A solution may be for jackson-coreutils to depend on Guava 18, 19 or 20. These all contain the class MoreObjects
as a duplicate of Objects
from Guava 16. So it may just be a matter of bumping the Guava version and substituting Objects
with MoreObjects
. Upstream code can then use Guava 21+ (which still contains these methods in MoreObjects
)
An alternative might be to just inline the calls to the utility functions in Objects
, if they are not used too frequently.
Related:
- Issue #8
- Pull request #5
Here's a 4-line patch that seems to do the trick. (One line of Java changed, and no other deprecation warnings found after updating to Guava 20.)
Is this ever going to get merged? We're on Guava 23 now
Have just created (my first ever) Pull Request. Hopefully this is trivial & risk-free enough to be picked up by the project maintainer.
@huggsboson I notice that you've helped the community get some pull requests into json-schema-validator
by taking it under the java-json-tools
umbrella ("organisation").
I don't suppose you'd consider doing the same with this dependency of that project? (It's included via json-schema-validator
). Unfortunately these projects all reference an old version of Guava which blocks higher-level projects from upgrading Guava due to a binary incompatibility. (Guava 23 is out now.) However I've made a minimalistic pull request here (#13) that would resolve this, which still allows these projects to continue to reference Guava 16 if they wish.
(Although I believe, without any Android experience myself, that it should be possible to upgrade them all to reference Guava 20 without breaking Android and Java 6 support.)