|Re: [cross-project-issues-dev] Is it time to update to Guava 18?|
HI On 25/03/2015 10:24, Andreas Sewe wrote:
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.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.
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
Back to the top