Community
Participate
Working Groups
See bug 428976 for more context. We should try to reduce the amount of places where our APIs expose Guava types (in general Predicate or Function, sometimes Guava-specific collection types) as this can cause problems for client code that has to interact with multiple components which uses different versions of Guava. If that is not possible (in a reasonable amount of time), we should at least properly declare these using OSGi "uses" directives in our MANIFEST.MF files. From what I understand (but I have not studied the subject in depth), this would allow detecting incompatibilities at installation/bundle resolution time instead of causing ClassCastExceptions and such at runtime.
I have started a more detailed review of the individual leaks at https://docs.google.com/spreadsheet/ccc?key=0AhmVlx-Le9HUdFlBRjlmN3NkRjBXLUdLYXlteXEwSmc&usp=sharing I'll post the results here when this is done.
Work is ongoing, see the following commits: 0b018a9542a16670b26b450ea1699161b3a6c797 879f7e3c1e9c269f77e0adaf769704c05db2d810 102f723cc362c66e8fdf927087cf65e68a0476bd 8779d9ee6b7dbf48cf489451bb9d23b251cfbb47 3be25dd21971ab91c70b103deb44b0c3b084acb1 1d6b4d3dd9805929e4e73a569cb82e2454a00fc1 751c9663323a0a2af859f2a7208fd8d3e3d2e874
Fixed by the following commits: edd5267653951da6104ceda031c9b622c4aeb016 4d5d6e9c0414f770e22cf76f53a0a902fa50a5b1 0305a35554387cade181c8feed35d875d7c84d6f f02ddf360587e4c3d75c0416e1ffac474c60eb65 72371df961b0befad2a376a22a45dbe9637eddd3 32af755ad98e206a13859374e7ad08709823489f 70fbf24f1c74efd39e9566ff3f4fd43ecd1553ed 23675bcfe7de9bfdf909af50f27d106c7d693eed e70d4d1d8a75fc30ad90012827ced52dc0fe7d8c 29521164a85eb7d7f110e6f9a7e71991521f829e 98dd4e684096355b759c57723ecea71b16232bea 43693203933bff5f975b43cdb7a47b92ec6f4f64 0b018a9542a16670b26b450ea1699161b3a6c797 879f7e3c1e9c269f77e0adaf769704c05db2d810 102f723cc362c66e8fdf927087cf65e68a0476bd 8779d9ee6b7dbf48cf489451bb9d23b251cfbb47 3be25dd21971ab91c70b103deb44b0c3b084acb1 1d6b4d3dd9805929e4e73a569cb82e2454a00fc1 751c9663323a0a2af859f2a7208fd8d3e3d2e874
To check for this, get the complete sources in your workspace and then for each plug-in: 1. Open the manifest editor and go to the "Runtime" tab. 2. Click on the "Calculate Uses" button at the right of the "Exported Packages" list. This can be relatively long for large plug-ins. 3. Got to the "MANIFEST.MF" tab. Lots of new "uses" directives have been added to each of the exported package. Check that no uses directive references a package starting with "com.google". An easy way to do this is to use incremental search (Ctrl+J) from the top of the MANIFEST.MF file and look for com.google. The only instances you should find are in "Require-Bundle" where we depend on Guava explicitly as a bundle. If you are using the sources straight from a Git clone, reset the changes to the MANIFEST.MF files. Do not commit the uses directives (we have not decided yet if/when we want to do this).
Validated as explained by Pierre-Charles on Sirius 1.0.0 M7 RC1 (http://download.eclipse.org/sirius/updates/milestones/1.0.0M7rc1/luna 1.0.0.201405030833).
Available in Sirius 1.0.0M7 (see https://wiki.eclipse.org/Sirius/1.0.0M7 & http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/tag/?id=v1.0.0M7).
(In reply to Pierre-Charles David from comment #0) > We should try to reduce the amount of places where our APIs expose Guava NB It is not APIs as such that matter. It is class loadability , so if a public API class has private inheritance/field construction of a Guava class then that is an exposed Guava version. Conversely Guava types in function signatures are probably not a problem.
