[
https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17500473#comment-17500473
]
Hai Zhang edited comment on COMPRESS-611 at 3/3/22, 3:32 AM:
-------------------------------------------------------------
Hi Gary,
Thanks for the reply!
If I understand correctly, IOUtils.EMPTY_LINK_OPTIONS is a public field in a
public class, so it is part of the API. However it is also this static field
that raised the required Android platform version of anything referencing
IOUtils to Android 8.0, so if we are to become compatible with Android 5.0
again, we have to change/remove this field which will break binary
compatibility. Will breaking this binary compatibility be possible?
Besides removing the IOUtils.EMPTY_LINK_OPTIONS field, it will also be
necessary to revert the archive stream implementations to use regular
java.io.File API in order to stay compatible with Android 5.0. The TarFile API
is fine though since it's a new API, and apps can fall back to the stream on
older Android versions.
I agree that Android 5.0 is 8 years old and everyone like supporting newer
platforms so that code can be written in a better way. My reason for keeping
Android 5.0 support was mentioned in my previous comment:
1. I did meet a real user running 5.0, and they were volunteering to help the
translation & testing of my open source app (
https://github.com/zhanghai/MaterialFiles ), so I'd like to keep supporting
users like them if possible.
2. Generally speaking, a lot of users in developing countries may still be
using older devices, so it seems to me supporting Android 5.0+ may also be a
good thing considering their circumstances.
3. According to
https://www.androidpolice.com/googles-latest-android-version-distribution-numbers-show-11-in-dead-heat-with-10/
, raising supported Android platform version from 5.0 to 8.0 will result in
the percentage of supported device to drop from 98% to 82.7%, a >10% decrease.
The default value for minimum supported SDK in Android Studio also seems to be
5.0 now. Even for developers with a more radical stance, afaik most of them are
still only setting the minimum to Android 6.0 (2 API levels higher) for now.
I totally understand this is an open source project and I appreciate your
contributions, so I won't have any complaints either way. Please let me know if
you think it will be feasible to keep classes compatible with Android 5.0 in
1.20 still compatible in 1.21+ - if not, I guess I'll have to pin this library
to 1.20 for some years :/
was (Author: dreamingincode):
Hi Gary,
Thanks for the reply!
If I understand correctly, IOUtils.EMPTY_LINK_OPTIONS is a public field in a
public class, so it is part of the API. However it is also this static field
that raised the required Android platform version of anything referencing
IOUtils to Android 8.0, so if we are to become compatible with Android 5.0
again, we have to change/remove this field which will break binary
compatibility. Will breaking this binary compatibility be possible?
Besides removing the IOUtils.EMPTY_LINK_OPTIONS field, it will also be
necessary to revert the archive stream implementations to use regular
java.io.File API in order to stay compatible with Android 5.0. The TarFile API
is fine though since it's a new API, and apps can fall back to the stream on
older Android versions.
I agree that Android 5.0 is 8 years old and everyone like supporting newer
platforms so that code can be written in a better way. My reason for keep
supporting Android 5.0 was mentioned in my previous comment:
1. I did meet a real user running 5.0, and they were volunteering to help the
translation & testing of my open source app (
https://github.com/zhanghai/MaterialFiles ), so I'd like to keep supporting
users like them if possible.
2. Generally speaking, a lot of users in developing countries may still be
using older devices, so it seems to me supporting Android 5.0+ may also be a
good thing considering their circumstances.
3. According to
https://www.androidpolice.com/googles-latest-android-version-distribution-numbers-show-11-in-dead-heat-with-10/
, raising supported Android platform version from 5.0 to 8.0 will result in
the percentage of supported device to drop from 98% to 82.7%, a >10% decrease.
The default value for minimum supported SDK in Android Studio also seems to be
5.0 now. Even for developers with a more radical stance, afaik most of them are
still only setting the minimum to Android 6.0.
I totally understand this is an open source project and I appreciate your
contributions, so I won't have any complaints either way. Please let me know if
you think it will be feasible to keep classes compatible with Android 5.0 in
1.20 still compatible in 1.21 - if not, guess I'll have to pin this library to
1.20 for years :/
> commons-compress 1.21 became incompatible below Android 8.0
> -----------------------------------------------------------
>
> Key: COMPRESS-611
> URL: https://issues.apache.org/jira/browse/COMPRESS-611
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.21
> Reporter: Hai Zhang
> Priority: Major
>
> The change
> https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae
> added a static LinkOption[] field into IOUtils, and also made use of
> LinkOption in tar code.
> However, LinkOption is a Java 8 class that's only available on Adnroid 8.0
> and beyond (added in API 26 according to
> https://developer.android.com/reference/java/nio/file/LinkOption ). And with
> the static field in IOUtils, which will result in loading the LinkOption
> class during IOUtils class initialization, this suddenly made all classes
> referencing IOUtils require Android 8.0.
> In comparision, most of the functionalities in commons-compress 1.20 was
> working fine on Android 5.0+.
> I discovered this because a real user wrote to me about this issue, and
> generally speaking a lot of users in developing countries may still be using
> older devices, so it seems to me supporting Android 5.0+ may still be a good
> thing. Meanwhile according to
> https://www.androidpolice.com/googles-latest-android-version-distribution-numbers-show-11-in-dead-heat-with-10/
> , raising supported Android platform version from 5.0 to 8.0 will result in
> the percentage of supported device to drop from 98% to 82.7%, a >10% decrease.
> So could you kindly consider supporting Android 5.0 again by making the usage
> of Java 8 NIO file APIs optional?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
