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?

Hi Ed,

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

I don't quite understand. What do you mean by "SimRel products". IMHO,
the burden is solely with bundles C which depend on multiple bundles A
and B that expose Guava in their API. If the developers of C do their
homework, then the maintainer of a "SimRel product" (I assume you mean
something like ann EPP package) does not have to worry about multiple
Guava's being shipped as part of that product.

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

I thought so, too, but (as Thomas Watson explained [1]) with Equinox
this is unfortunately not always the case. Here's the scenario:

 - Bundle A requires either Guava version X or Y
 - Bundle B requires Guava version Y
 - C requires both A and B.

All bundles have correct uses constraints.

 - A is installed first (causing version X to be installed)
 - Equinox wires A to X
 - B is installed second (causing version Y to be installed)
 - Equinox wires B to Y
 - C is installed
 - Equinox cannot wire C to A and B *without* requiring A to Y

As Equinox (without "-clean") won't rewire existing bundles, C cannot be
resolved, even though a solution exists.

A similar situation arises if C = B, i.e., C both requires Guava itself
and a bundle A that exposes Guava in its API. But with three bundles
things are easier to explain, even though the two-bundle scenario is
probably more common.

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

Sorry, I don't understand what you are saying here. Can you please
reword and possibly expand your explanation?

Best wishes,


[1] <>

Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Back to the top