|Re: [cross-project-issues-dev] Still issues with multiple Guava versions ... still time to fix them
I am not a class loader expert, so what I write is based on making sense of observations.
Perhaps the two scenarios are the same.
The explicit re-export is obviously bad since it forces everyone else to use that version.
From : https://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins
Exporting a version range that spans multiple major versions of a plug-in is not recommended, because it forces downstream plug-ins to support versions with arbitrary breaking changes between them.
Exporting just 15 would be restrictive. Exporting 10 to 15 would conflict with the guidance.
The subtle class load dependency is where the problem is actually coming from.
The following is, I think an example of a subtle class load dependency.
class Mine implements SomeGuavaClass
private static AnotherGuavaClass useful = new AnotherGuavaClass();
so even though Guava is not exported, loading Mine, which is exported, causes SomeGuavaClass and AnotherGuavaClass to be loaded by the overall class loader, which may have a problem if a different version of SomeGuavaClass is similarly loaded on behalf of some other component.
On 02/06/2014 12:51, Igor Fedorenko wrote:
Back to the top