Hi, I wanted to first understand what the priorities of the project are so i did not start yet.
Let's wait for the response of the author of the original jira. If he won't work on this I could try to make a PR on this. Have a nice day, David On Thu, Aug 12, 2021 at 11:53 AM Ryan Skraba <r...@skraba.com> wrote: > 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 >
