[
https://issues.apache.org/jira/browse/AVRO-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401529#comment-17401529
]
David Gang commented on AVRO-2863:
----------------------------------
Great!
I want to expand on the challenges we will face. In general the api of android
is documented here: [https://developer.android.com/reference/packages]
The android platform in general supports java6 style very well. Every new
android version, the android development team releases a new api version which
contains additional methods of the android platform. For examples java streams
were added in api 24. Here is a list of the android versions and their apis
from api level 23
||Android Major Version||Api version||
|6|23|
|7|24|
|8|26|
|9|28|
|10|29|
|11|30|
So the error we got here is that we want to support a lower api version but use
a function which does not exist there.
We have to decide which API version we want to support. I think that the 24
version is a good starting point. This may be too high for some apps but let's
release the initial version and see if people complain.
In the recent years there was another initiative from google called [API
desugaring|
https://developer.android.com/studio/write/java8-support#library-desugaring].
This means that newer apis like java8 time apis and streams can be accessed by
lower APIs. This may be relevant for avro time, because now it is using the new
java apis which is accessible from API26 but using api desugaring this would
solve the issue.
So i think we should document that we require at least API24 and the default
time handling needs api desugaring unless another logical type conversion is
done.
Now the bigger issue is that the android team released many reflection apis
just in api 26 and part of them did not port them at all. As Android phones
were weak in the past, the more common way is to have a more extensive code
generation phase which is instead of reflection. The reflection apis are also
not desugared as there is no much need for them compared to time api or
streams. A good example of a json serialization library which generates code
is moshi. Here is their code generator:
[https://github.com/square/moshi/tree/master/kotlin/codegen
|https://github.com/square/moshi/tree/master/kotlin/codegen]
So the available API is pretty the java6 reflection API. More info can be found
in the android reference above. What is your suggested strategy?
Do you want to switch back to java6 reflection? Do you want to check by
reflection if a certain class/ method is available and then decide on different
methods given the running java runtime ? What do you think on the bigger
picture? Please let me know if you want me to drill in on a certain part of
this comment.
> Avro 1.9.2 Java library does not work on Android
> ------------------------------------------------
>
> Key: AVRO-2863
> URL: https://issues.apache.org/jira/browse/AVRO-2863
> Project: Apache Avro
> Issue Type: Wish
> Components: java
> Affects Versions: 1.9.0, 1.9.1, 1.9.2
> Environment: Android 5.0.2 (API 21) up to the latest Android version,
> using Android Gradle plugin version 4.0.0.
> Reporter: Joris Borgdorff
> Priority: Major
> Fix For: 1.11.0
>
>
> One of our Android apps uses Avro to communicate with the server. Up to
> vision 1.8.2, it used a subset of the Avro library that was needed to perform
> this communication. It does not use any of the compress codecs and keeps the
> use of reflection to a minimum. Since Avro 1.9.0 a few blocking
> incompatibilities have been introduced. This prevents us from using any of
> the developments in Avro version 1.9.x, including the updated Jackson
> dependency.
> org.apache.avro.Schema uses ThreadLocal.withInitial, only available with
> Android API 26 (Android 8.0)
> org.apache.avro.reflect.ReflectUtils uses Method.invokeExact, not available
> on Android
> org.apache.avro.reflect.ReflectData uses java.lang.ClassValue, not available
> on Android
> I've experimented with excluding the org.apache.avro.reflect from the
> distribution (except MapEntry, which is used elsewhere) and providing my own
> java.lang.ClassValue implementation. This resolves all build and runtime
> issues for Android API 26 and above except for ThreadLocal.withInitial, which
> cannot be circumvented.
> For now the Android app will keep using 1.8.2, but we would prefer to use
> 1.9.2 or later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
