Ice4j v2.0.0 is not compatible with android < API-19 (Objects.requireNonNull)
cmeng-git opened this issue · 5 comments
Ice4j uses java.util.Objects class method Objects.requireNonNull(), which is only supported in android API level 19 and above. see https://developer.android.com/reference/java/util/Objects.
Smack also uses the same, but created its own org.jivesoftware.smack.util.Objects to allow smacks to be compatible with earlier android releases.
Would appreciate if ice4j development team would also consider the same support so it works on android < API-19
Actually I do not ready have any specific lower API to design for. It happen that I have both android devices S2 (API-15) and Note 2 (API-18) for testing. So far the Objects class is the one that limit aTalk to run on these two devices, currently aTalk is supporting API-15 min. The main reason to run aTalk on S2 is to get a feel of the UI response time on slow devices and other potential problems.
From user point of view, I would like to support till Android 4.1 (API-16). However my understanding from Android is that all new apk releases in 2018 are required to support 64-bit native libraries, which can only be generated with API-21 on NDK. Not sure what this means in apk releases with lower android API.
The reason for my request is that extending ice4j-2.0.0 support to lower API does not require major changes; and may be good for ice4j to offer this extension for wider usability of the library on other apk.
Currently in my project gradle, I am using jarjar tool to allow the ice4j-2.0.0 to run on API < 19 i.e.
jarjar2(jarfile: 'libs/ice4j-2.0.0.jar') {
zipfileset(src: 'lib/bundles/ice4j-2.0.0.jar')
rule pattern: 'java.util.Objects',
result: 'org.jivesoftware.smack.util.Objects'
}
My 2 cents (since I'm not the maintainer of this project):
You're just living on borrowed time. This library is not being actively tested on Android AFAIK, and less so on such old versions. Even API 19 is officially unsupported by Google, but in reality there are many Android 4.4.4 users out there.
Even if this problem is fixed there is no guaranty that things won't get broken tomorrow.
Even if this problem is fixed there is no guaranty that things won't get broken tomorrow.
I agree. This particular issue is trivial to avoid, because we only use requireNonNull
, so I wouldn't mind a PR
I somewhat do mind changing this, especially since it's apparently so easy to workaround it with jarjar2.
If changing it at all is really wanted, please do manual null checks and throwing IllegalArgumentExceptions, not a custom Objects class.