leventov / Koloboke

Java Collections till the last breadcrumb of memory and performance
https://koloboke.com/
1.01k stars 139 forks source link

Duplicate classes in jars — package-info #50

Open Alexander-- opened 8 years ago

Alexander-- commented 8 years ago

Both koloboke-impl and koloboke-impl-common are automatically fetched as part of project build. Both have a package-info.class file in com/koloboke/collect/impl. This causes Proguard builds (and presumably some other forms of library repackaging) to fail.

leventov commented 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.

Alexander-- commented 8 years ago

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.

leventov commented 8 years ago

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.