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

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi Ed,

> The analysis is indeed unclear because nobody has invested the time to
> debug the problem or solution.
> 
> My best theory seems to be all that there is:
> 
> The problem seems to arise for a project that integrates the Guava-based
> facilities of A and the Guava-based facilities of B, and when a Guava
> type reference/object from the A domain is checked in the B domain. The
> class loader appears to be able to make a Guava version choice for A
> without regard to B. This does not affect B which may happily use a
> different version Guava. The problem arises when an A-Guava type is
> checked by B. NB the precise meaning of 'checked by' is not clear to me.

The precise meaning is specified here [1], but "precise" unfortunately
doesn't imply "comprehensible". ;-)

That being said, I share your analysis that problems may occur whenever
a bundle C is wired to both bundles A and B which *expose* different
versions of Guava in their public API to C.

There are essentially two cases:

1) If A (wired to Guava version X) and B (wired to version Y) properly
declare uses constraints, then C will silently fail to resolve.

2) If A or B doesn't declare uses constraints, then C will fail at
runtime with a LinkageError or similar, as per [1].

There's also a variant of 1 where a solution to the constraint problem
does exist which would make C resolve, but Equinox will not find it and
needs a "-clean". See [2] for an example of this and [3] for a workaround.

> The hopeful solution is that if both A and B have 'uses' directives,
> then the class loader no longer has the ability to make an incompatible
> Guava choices for A and B.
> 
> So product teams for A and for B have no problem. It is the user of an
> integration of A and B who may suffer according to some unpredictable
> run-time class loading choices influenced by the number of Guava
> versions available on the classpath(s).

Well, if A and B require incompatible versions X and Y of Guava *and*
expose them in their API, then the developer of the integration C is to
blame.

If, however, A and B require compatible version (ranges) of Guava, then
[2] may occur, where an earlier wiring decision (wire A to version X and
B to version Y) will not be undone (*rewire* A and B to the same
version) and thus present a newly arrived bundle C from being resolved.

> Luna pre-RC4 nightmare: just look at the number of troublesome bug
> reports as Xtext/Acceleo/Code Recommenders/Mylyn interacted with 11,12,15
> 
> Luna RC4 fudge: only one version of Guava to make an unpredictable
> choice from.
> 
> Mars nightmare: someone introduces a second Guava version.

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.

Best wishes,

Andreas

[1]
<http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.3.4>
[2] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=438453>
[3] <https://git.eclipse.org/r/#/c/29698/>

-- 
Codetrails GmbH
The knowledge transfer company

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

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