Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Get rid of eclipse-collections as incompatible with Android #575
What changes were proposed in this pull request?
The Android Gradle build throws this kind of exception when eclipse-collections is included in a project:
Let's replace the only thing we use from it (DoubleArrayList) with the version from fastutil that gets pulled in by com.clearspring.analytics:stream anyway.
How was this patch tested?
Unit tests pass.
Unless I've misunderstood the cause (that being different versions of the same dependency), wouldn't this be solved easier by aligning the DL4J and DataVec versions of Eclipse Collections? That's a 1-line change in DL4J...
Otherwise we're effectively decided with this PR not to use Eclipse Collections in DataVec in the future, as any reintroduction (unless versions are aligned) would break Android again... Eclipse Collections has some nice classes/utils, so I'd like to avoid that unless there's no other option here.
So effectively you're effectively telling me we have to entirely and permanently remove Eclipse Collections from all of our libraries if we want to work on Android?! o_O
We use it (only a few places, mainly the primitive collections) in DataVec, Arbiter and DL4J.
Anyway, do we have any insight beyond that exception stack trace as to why this occurs?
It's been added to DataVec recently yes: a1f288e
The other modules where it's used have simply never been used by anyone on Android, that's all.
A search for Android on the Eclipse Collections repository returns nothing, so it just looks like no one has ever used it on Android: https://github.com/eclipse/eclipse-collections/search?utf8=%E2%9C%93&q=android&type=
The alternative is to exclude eclipse-collections manually for Android builds. That works, I don't think we'll be having users complaining about not being able to use PathMultiLabelGenerator anytime soon, and we can document that. Would you prefer that?
An exclusion probably isn't the best idea... someone, somewhere, will use that on android and then we'll have to fix it then anyway. :)
Maybe let's merge this for now, and open an issue to consider the other uses of Eclipse collections later.