You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@avro.apache.org by David Gang <dg...@lightricks.com> on 2021/08/11 14:13:47 UTC
android support in avro java libraries
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
Re: android support in avro java libraries
Posted by David Gang <dg...@lightricks.com>.
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 <ry...@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 <ry...@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
>
Re: android support in avro java libraries
Posted by Ryan Skraba <ry...@skraba.com>.
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 <ry...@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
Re: android support in avro java libraries
Posted by David Gang <dg...@lightricks.com>.
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 <ry...@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
>>
>
Re: android support in avro java libraries
Posted by David Gang <dg...@lightricks.com>.
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 <ry...@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
>
Re: android support in avro java libraries
Posted by Ryan Skraba <ry...@skraba.com>.
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