Thanks for the reference material! I linked the JIRA to this conversation too.
If AVRO-2863 has listed all the necessary changes (some minor code changes in core, filtering out the .reflect package and removing the use of `Thread.withInitial`) then I don't really see any objection to doing option 1 as a quick win, creating an `avro-android-1.11.0.jar` artifact for the next release. Have you already done some of this work internally? I asked the original author if he'd be willing to share his experiments -- with a bit of helpful expertise, I don't see why this wouldn't be doable for the next major release. Ryan On Wed, Aug 11, 2021 at 5:49 PM David Gang <dg...@lightricks.com> wrote: > > Hi, > > If needed I could give here more detailed guidance. > BR, > > On Wed, Aug 11, 2021 at 5:52 PM David Gang <dg...@lightricks.com> wrote: >> >> Hi, >> >> Thanks for the quick response. I think that the jira issue AVRO-2863 >> summarizes the issues. >> When talking about android support it is also important to decide which >> android version you want to support. This is normally based on distribution >> statistics: https://www.appbrain.com/stats/top-android-sdk-versions >> There are two main problems. Classes which won't be implemented by android >> platform (like ClassValue) and APIs which are just implemented by later >> versions. >> >> So when deciding that android is a platform which should be supported there >> are two options: >> >> 1. Not using classes which are not part of the android runtime (There are >> very few) >> 2. Create two flavors of the library. For example guava have guava android >> and guava jre. >> >> The first option is easier to handle but i am not sure what the impact on >> the product will be. The second option would (maybe) better for performance >> but be more complicate to handle. >> >> Besides this it is also important to decide for an avro library version what >> the minimal android version it supports. >> >> Regarding how to catch this stuff, this is a hard question. The only idea I >> have is to introduce a regression test which should run in your CI system. >> Mockito had the same problems and this is the solution they did: >> https://github.com/mockito/mockito/issues/2341 The regression test could be >> run on emulators with different versions (or maybe robolectrics) and so >> errors could be catched. >> >> Hope this answers roughly the questions. >> >> Thanks, >> >> >> >> On Wed, Aug 11, 2021 at 5:28 PM Ryan Skraba <r...@skraba.com> wrote: >>> >>> Hello! I don't think it was a conscient choice in 1.9+ to "drift" >>> away from android platform compatibility, and it's certainly worth the >>> effort to make Avro usable for android developers. >>> >>> What would it take to bring the Java caode back into a compatible >>> state? Would we need to separate out some of the core functionality? >>> Are there tools for detecting android incompatibility that we could >>> put into the build process? I'm not an android developer in the >>> slightest so any guidance or contribution would be helpful. >>> >>> Ryan >>> >>> On Wed, Aug 11, 2021 at 4:14 PM David Gang <dg...@lightricks.com> wrote: >>> > >>> > Hi, >>> > >>> > Does the developer team want to support the android platform? >>> > >>> > We are evaluating to use this library on android and got the exception of >>> > jira issue: https://issues.apache.org/jira/browse/AVRO-2863. >>> > >>> > Currently version 1.8.2 satisfies all our requirements but we want to >>> > know what the general attitude towards the android platform is. >>> > >>> > >>> > Thanks
