Re: [cross-project-issues-dev] Is it time to update to Guava 18?

[Ed Willink <ed@xxxxxxxxxxxxx>]

HI

On 25/03/2015 10:24, Andreas Sewe wrote:
> Possibly, but being open to third-party plugins, we cannot prevent the
> presence of multiple Guava versions in general.
>
> Anyway, I think the burden is on the developers of integration bundles
> C. You *can* shield yourself from this problem (A and B both exposing
> Guava in their API) to wrap one of them into facade that does not expose
> Guava in its API.
>
>    +-- A (exposes X) -- X
>   /
> C
>   \
>    +-- B' -- B (exposes Y) -- Y
>
> That way, A and B can be wired to different versions of Guava (X and Y,
> respectively) but C can still make use of them both.
>
> Granted, this is cumbersome, but (given the way OSGi and Equinox work)
> the only solution that is will work in an open ecosystem where *anyone*
> may supply another Guava bundle.
Yes. That could work, but not for Mars because it imposes a new 
requirement on all SimRel products that integrate multiple Guava users. 
But it severely undermines Eclipse as a useful integration platform.

IMHO, and I think 'uses' does this, then if A and B announce what they 
use, then the class loader for the integrator chooses a jointly 
compatible Guava. If this fails, most commonly this will be a compile 
time version failure because A  and B have no overlap; an integrator's 
bug. Rarely it may occur at run-time if no Guava version from the 
overlap is available, a user's bug. Both are sensible, diagnosable and 
fixable leaving Eclipse as a good flexible integration platform.

    Regards

        Ed Willink