[
https://issues.apache.org/jira/browse/NET-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834088#comment-17834088
]
Gary D. Gregory edited comment on NET-729 at 4/4/24 9:48 PM:
-------------------------------------------------------------
[~hlindqvi]
>Android 7 was released in 2016, that's 8 years old not 14
Right, that's my mixing Android version and Android API version, sorry about
that, I had looked up _API_ version 7.
> It seems "binary compatibility" was broken in version 1.3.9, so any reverting
> would actually restore it.
We never had a 1.3.9, we had 1.3.0 and 1.4.0, surely you can't be suggesting we
revert... what to what exactly? That would likely break binary compatibility,
but one can't tell without trying.
I agree that backwards compatibility is important but there are different
meanings to this, and here, so far, JLS binary compatibility has been the main
concern, helped by the fact that this is easily verifiable with a Maven plugin
(JApiCmp here, other projects use revapi)
Unless there is a way to check at build time with a Maven plugin what Android
compatibility is required and/or is broken for a given version, there isn't
much we can do. With a plugin, we could then document what version is required
and make a note when that changes. Or decide we don't want to change the
Android req.
was (Author: garydgregory):
[~hlindqvi]
>Android 7 was released in 2016, that's 8 years old not 14
Right, that's my mixing Android version and Android API version, sorry about
that, I had looked up _API_ version 7.
> It seems "binary compatibility" was broken in version 1.3.9, so any reverting
> would actually restore it.
We never had a 1.3.9, we had 1.3.0 and 1.4.0, surely you can't be suggesting we
revert... what to what exactly? That would likely break binary compatibility,
but one can't tell without trying.
I agree that backwards compatibility is important but there are different
meanings to this, and here, so far, JLS binary compatibility has been the main
concern, helped by the fact that this is easily verifiable with a Maven plugin
(JApiCmp here, other projects use revapi)
Unless there is a way to check at build time with a Maven plugin what Android
compatibility is required and/or is broken for a given version, there isn't
much we can do. With a plugin, we could then document what version is required
and make a note when that changes.Or decide we don't want to change the Android
req.
> Undisclosed Java 8 requirement.
> -------------------------------
>
> Key: NET-729
> URL: https://issues.apache.org/jira/browse/NET-729
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.9.0, 3.10.0
> Environment: Android 7 and lower
> Reporter: Henrik Lindqvist
> Priority: Minor
> Fix For: 3.11.0
>
>
> Has for a decade been using this library in an Android app. Decided to update
> from an older version to 3.10.0 mostly for the fixed security issue, but this
> is sadly not possible due to version 3.9.0 now requires Java 8 which Android
> lacks full support for, e.g. it's missing java.time.Duration. It's
> unfortunate that such unnecessary changes are made, replacing working code
> with new Java features just for the fun of it, since this will force projects
> use another dependency making this library even more irrelevant. Please
> revert the changes that use Java 8 features, or at least update the
> documentation with a notice that version 3.9.0 is not binary compatible with
> prior versions: [https://commons.apache.org/proper/commons-net/migration.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
