Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Is it time to update to Guava 18?


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
   +-- 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.


        Ed Willink

Back to the top