Open Alexander-- opened 8 years ago
Thanks for the finding.
Before it is fixed in future versions, you could use koloboke version net.openhft:koloboke-api/koloboke-impl:0.6.8
(pre impl/impl-common separation). You should only check that the bug fixed in 1.0.0 (see https://github.com/leventov/Koloboke/releases/tag/lib-1.0.0) doesn't affect you.
You could also try to use Koloboke Compile: https://koloboke.com/compile, which requires only ~ 1 MB of runtime dependencies: koloboke-api
and koloboke-impl-common
, but not koloboke-impl
, which is 18 MB alone, so with Koloboke Compile you don't probably need Proguard. And even if you use Proguard anyway, since Koloboke Compile doesn't require koloboke-impl
, it should be unaffected by this issue.
Got it to work with current version after allowing Proguard to strip Koloboke classes (which removes package-info since it is unreferenced by other classes). Many people use all-or-nothing Proguard configs, which is probably be why this problem took a while to notice.
More likely, because impl/impl-common separation was introduced just in the latest released version a couple of months ago. Little number of people is moved to this version already. Anyway, this issue should be fixed in the next version.
Both koloboke-impl and koloboke-impl-common are automatically fetched as part of project build. Both have a
package-info.class
file incom/koloboke/collect/impl
. This causes Proguard builds (and presumably some other forms of library repackaging) to fail.