Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Still issues with multiple Guava versions ... still time to fix them


Please excuse the lengthy reply, I'm trying to clarify many confusions.

My viewpoint

My projects depend heavily on Xtext, so they just 'inherit' the Xtext dependency. I do not have a problem. However when I see my projects used in a larger system I see pain and consequently feel a responsibility to highlight this cross-project issue.

The problem

The symptom of the problem is a Class loading failure reporting conflicting versions of a Guava class.

This can obviously occur if :
a Class loader for component A has loaded Guava class G on behalf of itself or component A
and subsequently:
the same class loader attempts to load  a different G on behalf of component B or itself.

In dealing with this problem we seem to need to consider class loading dependencies rather than non-provate API. Thus even if a plugin keep its version of Guava 100% 'private', it nonetheless exports a Guava class loading dependency if any externally loadable class inherits from a Guava class or constructs a Guava field. Use of Guava in function argument types does not appear to cause class loading and so is not a problem.

Within OSGI each plugin has its own class loader so it is possible for well behaved components A and B to co-exist with different Guava versions, just so long as an integrating application is not able to construct anything from both A and B.

For standalone applications there is only one class loader and so any conflicts between components A and B in the same application can be killers.

These problems have not been 100% reproducible. Within Eclipse the amount of lazy functionality, such as the concurrent EMF live validation thread, means that the order of class loading is not repeatable and so the order of Guava loading can vary. I'm not entirely clear as to whether a class loader faced with an a choice makes a consistent resolution, or is perhaps influenced by previously loaded packages.


The first problem arose when Guava 12 became available with a BREE 6. Consequently the many Java 5 upwards Kepler distributions started to fail. For me the problem went away by changing my test launch configurations to BREE >= 6. Once org.eclipse.osgi.utils went to BREE 6, any pretense of Java 5 support vanished and so this is a non-issue.

[Of course if API tooling warned about a BREE outside the transitive non-optional dependence BREE we would avoid these confusions.]
Guava re-export

The next problem arose when Xtext re-exported a narrow Guava range leaving the Eclipse class loader confused. The re-export was corrected before it made it into a milestone build

Multiple Guava

Problems for large applications such as Papyrus have come and gone and come back again. They went away as Guava dependencies were widened so that the second user tolerated whatever was first loaded. They have come back with partial migration to Guava 15 which is outside the earlier wide bounds.


The reliable solution of making Guava a singleton is unacceptable to the community as a whole.

So we must make the best of it. I think we need to try to observe

a) Guava must not be exported and so avoid OSGI class loader confusion.
- API tooling could warn if any non-singleton plugin is exported.

b) Requirements to load Guava classes must not be exported
- API tooling could warn if a class in a non-singleton plugin is externally class loadable

c) All plugins that may be used in standalone applications must have a version bound that includes the latest Guava in Orbit (and as may other versions as possible)
- SimRel tooling could at least report two lists of plugins that exclude the latest version in Orbit, one with and one without a non-optional OSGI dependency.


        Ed Willink

On 02/06/2014 06:07, David M Williams wrote:
This has been discussed before, but apparently is still causing problem. The most recent bug I've seen is
but also

The original bug where this was discussed was

Here's the "picture" from most recent "repo report"

Four versions is probably a record! If I may refresh your memory, to be part of the Simultaneous Release repo requires using "the latest version from Orbit unless there is a technical reason not to".
And sometimes there are technical reasons to have/use multiple versions ... but even then that's ok to do only as long as it meets the "cause no harm" prime directive.

So, please re-evaluate the version you pre-req, your and your adopters needs, and whether or not you are committed to being in the Simultaneous Release Repository.

For those of you that find problems with having multiple version, please detail the steps to reproduce the problem, so the Planning Council can better understand the severity of the problem, and it's likely hood of occurring in the field. We may be in the unfortunate position of saying some projects can not be in "simultaneous release repo" [Your project can still release, from your own project's repo ... just not from the Simultaneous Release repo]. And, note, if some do have to be omitted, "fairness" or "only those using most recent" are not really the criteria we'll use, ... we'll just be looking to "do the least harm" to the community.

I'll make more comments in the bugs ... as should you who use Guava ... but I'd rather spend my time giving advice on how to solve the problem, rather than deciding who can't be in the repository ... so, your cooperation in making my life more pleasant would be appreciated.


cross-project-issues-dev mailing list

No virus found in this message.
Checked by AVG -
Version: 2014.0.4592 / Virus Database: 3955/7603 - Release Date: 06/01/14

Back to the top