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

    Regards

        Ed Willink

On 25/03/2015 09:30, Andreas Sewe wrote:

Hi Ed, hi Wayne,


See https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107

in that bug report I frankly miss a clear analysis as to *why* different
Guava bundles are a problem.

Agreed, incorrect metadata is always a problem in OSGi, such as bundles
exporting com.google.common packages without versions or uses
directives, but at least from Orbit's Guava 12 on this is no longer the
case. This does not prevent non-Eclipse projects from publishing another
Guava bundle with incorrect metadata, of course -- but any
Eclipse-internal policy won't stop them either.


The Luna experience was that in the absence of tooling, all projects
MUST use the same Guava, which should be the latest in Orbit.

Mixed Guava is a disaster. So far nobody seems to have moved for Mars.

I just ran a quick test for Eclipse Code Recommenders to assess the
number of API changes in Guava between version 15 and 18 that would
affect our codebase.

Luckily, the list is very short:

- Files.newInputStreamSupplier(File) gone in Guava 18.0

Of course, you would still need to verify that the *behavior* of the
remaining API didn't change. Just because it compiles doesn't mean it works.

FWIW, if other projects want to do this kind of quick-and-dirty check
("Does it still compile?"), it's surprisingly easy with Tycho:

- Use pomDependencies=consider in your target-platform-configuration [1]
- Add a POM dependency to com.google.guava:guava:18.0 (the artifact in
   Maven central has proper OSGi headers)
- Use seasrch-and-replace to update your Import-Package and Require-
   Bundle headers
- Run "mvn clean install" on the projects in question, possible
   building them one by one with -pl :artifactId, as earlier compile
   errors will prevent latter modules from being build at all

Hope this helps others to get a lower bound on the cost that such a
change would impose on their projects.


If we are to move, I think we should all aim to move in I-builds
immediately following M6.

There may be a maintenance issue. e.g. Xtext 2.8.0 is out,so moving to
Guava 18 might force a 2.9.0.

I feel that barely a day before M6 is too late to request this.

Wayne Beaton wrote:

More generally, I think that we need a policy for these widely-shared
libraries. Intuitively, it makes sense to me that we should try to use
the most recent version released in Orbit with the simultaneous release.

Thoughts?

The big problem with this policy is that it forces projects to maintain
branches for Luna (using the Guava 15 API) and Mars (using the Guava 18
API). Moreover, it forces users to pick the right update site, e.g.,
updates/luna/stable vs. just updates/stable.

Now, Code Recommenders did maintain a branch before (to account for some
changes to the JDT APIs with Kepler, IIRC) and offered special fragments
for Juno and later versions, respectively, but it complicated our build
and testing quite a bit. Of course, integration with JDT is arguably
core to Code Recommenders, so here branching was indeed a necessity.

For a library, however, which supplies only "trivial" stuff like
Optional and Multimaps, I would like to avoid the maintenance overhead
of branches or fragments *unless* someone can clearly demonstrate and
explain why it is absolutely necessary. IMHO, the discussion in Bug
437107 has so far failed to do that.

Just my 2 cents.

Andreas

[1]
<http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts>

Back to the top