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 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev