[
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771136#comment-16771136
]
Robert Munteanu commented on OAK-7182:
--------------------------------------
[~stillalex] - I eventually managed to take a look at your diff. The fact that
you had to basically replicate the Guava API in a compat layer is indeed a bad
smell.
I would suggest that - if needed - we simply do away with the Guava APIs and
implement our own, e.g. instead of having
{{org.apache.jackrabbit.oak.commons.guava.MoreExecutorsCompat}} we have a
{{org.apache.jackrabbit.oak.commons.concurrent.OakExecutors}} where we supply
whatever is needed by Oak under our own APIs. I have come to strongly believe
that any leak of Guava APIs in the Oak codebase - whether it's in exported API
or not - is a risk. Therefore I would favour only accessing it from a limited
amount of classes so migration to newer version (or even away from Guava) is
possible.
I think that the only way this can eventually work is to no longer import Guava
at runtime, either by replacing it completely or by importing it statically and
shading it (optional rant below).
----
For more context, I believe that it's important that we understand where Guava
is coming from. Google famously stores all it's code in a monorepo (
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
). Not only is all the code stored in a single repository - including shared
libraries like Guava and external dependencies like JUnit, but also all
dependencies are upgraded _at the same time_. This means that all projects in
trunk depend on a single version of Guava at a single point in time.
For this kind of setup the way Guava does versioning and backwards
compatibility is perfectly fine - you give everyone time to adapt to new
releases and then stop supporting the old code. However, it is fundamentally at
odds with being used in projects with a large number of dependencies, each one
having its own Guava version. This is precisely why we must minimise our
exposure to Guava and keep it behind adapter classes or even remove it outright.
The sooner we do this the better.
> Make it possible to update Guava
> --------------------------------
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
> Issue Type: Wish
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff,
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff,
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in
> order to make updates possible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
