[jira] [Commented] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500483#comment-17500483 ] Gary D. Gregory commented on COMPRESS-611: -- Hi [~dreamingincode] Thank you for your detailed explanation. I do not see us breaking binary compatibility on purpose to support Android 5.0. Maintaining binary compatibility is extremely important to avoid jar hell and breaking applications. Your best and simplest path is to use version 1.20. Gary > 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)
[jira] [Comment Edited] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 >
[jira] [Commented] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500473#comment-17500473 ] Hai Zhang commented on COMPRESS-611: 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)
[jira] [Commented] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500467#comment-17500467 ] Gary D. Gregory commented on COMPRESS-611: -- Hello [~dreamingincode] Thank you for you your report. I don't quite see how to do what you want without breaking binary compatibility. If you have any ideas, please let us know or create a PR on GitHub so we can see exactly how you would do that. TBH, I can't say that I consider keeping compatibility with an 8 year old version of Android a factor in my work here. But, if you have any ideas, let us know. > 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)
[GitHub] [commons-configuration] garydgregory commented on pull request #37: Configuration-766: BigDecimal(double) should not be used.
garydgregory commented on pull request #37: URL: https://github.com/apache/commons-configuration/pull/37#issuecomment-1057612116 @HarisAdzemovic May you please rebase on master? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hai Zhang updated COMPRESS-611: --- Description: 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? was: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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? > 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)
[jira] [Updated] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hai Zhang updated COMPRESS-611: --- Description: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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? was: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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? > 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[] array 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)
[jira] [Updated] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hai Zhang updated COMPRESS-611: --- Description: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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? was: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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 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? > 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[] array 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 to 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)
[jira] [Updated] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hai Zhang updated COMPRESS-611: --- Description: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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 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? was: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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 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 decrease 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? > 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[] array 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 to 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 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)
[jira] [Updated] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
[ https://issues.apache.org/jira/browse/COMPRESS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hai Zhang updated COMPRESS-611: --- Description: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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 to 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 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 decrease 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? was: The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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. 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 to 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 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 decrease 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? > 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[] array 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 to 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 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 decrease 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)
[jira] [Created] (COMPRESS-611) commons-compress 1.21 became incompatible below Android 8.0
Hai Zhang created COMPRESS-611: -- Summary: 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 The change https://github.com/apache/commons-compress/commit/06e05dab3bcb9044cc599f0ff18be78c54a8fbae added a static LinkOption[] array 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. 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 to 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 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 decrease 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)
[GitHub] [commons-configuration] garydgregory merged pull request #139: Replace test asserts by simpler but equivalent calls.
garydgregory merged pull request #139: URL: https://github.com/apache/commons-configuration/pull/139 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory merged pull request #141: Make final variable.
garydgregory merged pull request #141: URL: https://github.com/apache/commons-configuration/pull/141 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory merged pull request #143: Update tests to hamcrest v2.2
garydgregory merged pull request #143: URL: https://github.com/apache/commons-configuration/pull/143 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory merged pull request #159: Bump jackson-databind from 2.12.4 to 2.13.1
garydgregory merged pull request #159: URL: https://github.com/apache/commons-configuration/pull/159 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory edited a comment on pull request #161: Bump hsqldb from 2.5.2 to 2.6.1
garydgregory edited a comment on pull request #161: URL: https://github.com/apache/commons-configuration/pull/161#issuecomment-1057551372 Closing; requires Java 11. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory closed pull request #161: Bump hsqldb from 2.5.2 to 2.6.1
garydgregory closed pull request #161: URL: https://github.com/apache/commons-configuration/pull/161 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] commented on pull request #161: Bump hsqldb from 2.5.2 to 2.6.1
dependabot[bot] commented on pull request #161: URL: https://github.com/apache/commons-configuration/pull/161#issuecomment-1057551393 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory commented on pull request #161: Bump hsqldb from 2.5.2 to 2.6.1
garydgregory commented on pull request #161: URL: https://github.com/apache/commons-configuration/pull/161#issuecomment-1057551372 Closing requires Java 11. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-pool] garydgregory merged pull request #131: Simplify test assertion with similar call but simpler.
garydgregory merged pull request #131: URL: https://github.com/apache/commons-pool/pull/131 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] nhojpatrick commented on pull request #282: JUnit v5 assertThrows no2
nhojpatrick commented on pull request #282: URL: https://github.com/apache/commons-collections/pull/282#issuecomment-1057467757 @kinow @garydgregory could you both confirm what style you require? each pr I feel I need to do a different style, one PR I get told to keep comments and check thrown exception message and next PR i'm being asked to not do that due to maintainer overhead. I'm happy to do either way. I've got 673 more assertions on my list to refactor, so would like to know beforehand what I aiming for. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-777) Fully migrate Commons Collection to JUnit 5
[ https://issues.apache.org/jira/browse/COLLECTIONS-777?focusedWorklogId=735643=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-735643 ] ASF GitHub Bot logged work on COLLECTIONS-777: -- Author: ASF GitHub Bot Created on: 02/Mar/22 22:38 Start Date: 02/Mar/22 22:38 Worklog Time Spent: 10m Work Description: nhojpatrick commented on pull request #283: URL: https://github.com/apache/commons-collections/pull/283#issuecomment-1057464508 Passed locally but that was before squash, making draft and checking again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 735643) Time Spent: 20m (was: 10m) > Fully migrate Commons Collection to JUnit 5 > --- > > Key: COLLECTIONS-777 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-777 > Project: Commons Collections > Issue Type: Improvement > Components: Core >Reporter: Arturo Bernal >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The idea it's fully migrate Commons Collection to JUnit 5. This time i'll > split the work in sub-task in order to avoid PR with to many files -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-collections] nhojpatrick commented on pull request #283: COLLECTIONS-777 JUnit v5
nhojpatrick commented on pull request #283: URL: https://github.com/apache/commons-collections/pull/283#issuecomment-1057464508 Passed locally but that was before squash, making draft and checking again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] nhojpatrick commented on a change in pull request #281: JUnit v5 assertThrows
nhojpatrick commented on a change in pull request #281:
URL:
https://github.com/apache/commons-collections/pull/281#discussion_r818161889
##
File path:
src/test/java/org/apache/commons/collections4/trie/PatriciaTrieTest.java
##
@@ -243,28 +242,26 @@ public void testPrefixMap() {
map = trie.prefixMap("Ab");
Assertions.assertTrue(map.isEmpty());
Assertions.assertEquals(0, map.size());
-try {
-final Object o = map.firstKey();
-Assertions.fail("got a first key: " + o);
-} catch(final NoSuchElementException nsee) {}
-try {
-final Object o = map.lastKey();
-Assertions.fail("got a last key: " + o);
-} catch(final NoSuchElementException nsee) {}
+
+final SortedMap map1 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map1.firstKey());
+
+final SortedMap map2 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map2.lastKey());
+
iterator = map.values().iterator();
Assertions.assertFalse(iterator.hasNext());
map = trie.prefixMap("Albertooo");
Assertions.assertTrue(map.isEmpty());
Assertions.assertEquals(0, map.size());
-try {
-final Object o = map.firstKey();
-Assertions.fail("got a first key: " + o);
-} catch(final NoSuchElementException nsee) {}
-try {
-final Object o = map.lastKey();
-Assertions.fail("got a last key: " + o);
-} catch(final NoSuchElementException nsee) {}
+
+final SortedMap map3 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map3.firstKey());
+
+final SortedMap map4 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map4.lastKey());
Review comment:
I keep getting told to drop the failure message or not check the
exception message, so assumed that is the apache commons standard. I can
change, but it's slightly confusing as each apache commons pr review appears to
have different criterial or standards that I need to follow.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-777) Fully migrate Commons Collection to JUnit 5
[ https://issues.apache.org/jira/browse/COLLECTIONS-777?focusedWorklogId=735641=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-735641 ] ASF GitHub Bot logged work on COLLECTIONS-777: -- Author: ASF GitHub Bot Created on: 02/Mar/22 22:34 Start Date: 02/Mar/22 22:34 Worklog Time Spent: 10m Work Description: nhojpatrick opened a new pull request #283: URL: https://github.com/apache/commons-collections/pull/283 Again similar to https://github.com/apache/commons-collections/pull/281 and https://github.com/apache/commons-collections/pull/282 another load of JUnit v5 assertThrows for [COLLECTIONS-](https://issues.apache.org/jira/browse/COLLECTIONS-777) JUnit v5 assertThrows PredicatedBagTest JUnit v5 assertThrows PredicatedSortedBagTest JUnit v5 assertThrows TreeBagTest JUnit v5 assertThrows AbstractBagTest JUnit v5 assertThrows AbstractBidiMapTest JUnit v5 assertThrows AbstractOrderedBidiMapTest JUnit v5 assertThrows PredicateUtilsTest JUnit v5 assertThrows MultiMapUtilsTest JUnit v5 assertThrows EnumerationUtilsTest JUnit v5 assertThrows ArrayStackTest -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 735641) Remaining Estimate: 0h Time Spent: 10m > Fully migrate Commons Collection to JUnit 5 > --- > > Key: COLLECTIONS-777 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-777 > Project: Commons Collections > Issue Type: Improvement > Components: Core >Reporter: Arturo Bernal >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The idea it's fully migrate Commons Collection to JUnit 5. This time i'll > split the work in sub-task in order to avoid PR with to many files -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-collections] nhojpatrick opened a new pull request #283: COLLECTIONS-777 JUnit v5
nhojpatrick opened a new pull request #283: URL: https://github.com/apache/commons-collections/pull/283 Again similar to https://github.com/apache/commons-collections/pull/281 and https://github.com/apache/commons-collections/pull/282 another load of JUnit v5 assertThrows for [COLLECTIONS-](https://issues.apache.org/jira/browse/COLLECTIONS-777) JUnit v5 assertThrows PredicatedBagTest JUnit v5 assertThrows PredicatedSortedBagTest JUnit v5 assertThrows TreeBagTest JUnit v5 assertThrows AbstractBagTest JUnit v5 assertThrows AbstractBidiMapTest JUnit v5 assertThrows AbstractOrderedBidiMapTest JUnit v5 assertThrows PredicateUtilsTest JUnit v5 assertThrows MultiMapUtilsTest JUnit v5 assertThrows EnumerationUtilsTest JUnit v5 assertThrows ArrayStackTest -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] kinow commented on a change in pull request #281: JUnit v5 assertThrows
kinow commented on a change in pull request #281:
URL:
https://github.com/apache/commons-collections/pull/281#discussion_r818149695
##
File path:
src/test/java/org/apache/commons/collections4/trie/PatriciaTrieTest.java
##
@@ -274,14 +271,13 @@ public void testPrefixMap() {
map = trie.prefixMap("\0");
Assertions.assertTrue(map.isEmpty());
Assertions.assertEquals(0, map.size());
-try {
-final Object o = map.firstKey();
-Assertions.fail("got a first key: " + o);
-} catch(final NoSuchElementException nsee) {}
-try {
-final Object o = map.lastKey();
-Assertions.fail("got a last key: " + o);
-} catch(final NoSuchElementException nsee) {}
+
+final SortedMap map5 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map5.firstKey());
+
+final SortedMap map6 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map6.lastKey());
Review comment:
Ditto here.
##
File path:
src/test/java/org/apache/commons/collections4/trie/PatriciaTrieTest.java
##
@@ -243,28 +242,26 @@ public void testPrefixMap() {
map = trie.prefixMap("Ab");
Assertions.assertTrue(map.isEmpty());
Assertions.assertEquals(0, map.size());
-try {
-final Object o = map.firstKey();
-Assertions.fail("got a first key: " + o);
-} catch(final NoSuchElementException nsee) {}
-try {
-final Object o = map.lastKey();
-Assertions.fail("got a last key: " + o);
-} catch(final NoSuchElementException nsee) {}
+
+final SortedMap map1 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map1.firstKey());
+
+final SortedMap map2 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map2.lastKey());
+
iterator = map.values().iterator();
Assertions.assertFalse(iterator.hasNext());
map = trie.prefixMap("Albertooo");
Assertions.assertTrue(map.isEmpty());
Assertions.assertEquals(0, map.size());
-try {
-final Object o = map.firstKey();
-Assertions.fail("got a first key: " + o);
-} catch(final NoSuchElementException nsee) {}
-try {
-final Object o = map.lastKey();
-Assertions.fail("got a last key: " + o);
-} catch(final NoSuchElementException nsee) {}
+
+final SortedMap map3 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map3.firstKey());
+
+final SortedMap map4 = map;
+Assertions.assertThrows(NoSuchElementException.class, () ->
map4.lastKey());
Review comment:
Maybe keep the comments above. I don't know what first or last key
represent in this case, but I assume it could be useful to see that in the test
failure output (I guess that's why the original developer put them there).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-collections] kinow commented on a change in pull request #282: JUnit v5 assertThrows no2
kinow commented on a change in pull request #282:
URL:
https://github.com/apache/commons-collections/pull/282#discussion_r818145413
##
File path:
src/test/java/org/apache/commons/collections4/comparators/ComparatorChainTest.java
##
@@ -67,11 +68,8 @@ public void testBadNoopComparatorChain() {
final ComparatorChain chain = new ComparatorChain<>();
final Integer i1 = 4;
final Integer i2 = 6;
-try {
-chain.compare(i1, i2);
-fail("An exception should be thrown when a chain contains zero
comparators.");
-} catch (final UnsupportedOperationException e) {
-}
+
+assertThrows(UnsupportedOperationException.class, () ->
chain.compare(i1, i2));
Review comment:
I think the error message would be helpful in this case :point_up: maybe
add that to the `assertThrows`
##
File path:
src/test/java/org/apache/commons/collections4/iterators/ListIteratorWrapper2Test.java
##
@@ -109,11 +110,7 @@ public void testRemove() {
assertEquals(-1, iter.previousIndex());
assertEquals(0, iter.nextIndex());
-try {
-iter.remove();
-fail("ListIteratorWrapper#remove() should fail; must be initially
positioned first");
-} catch (final IllegalStateException e) {
-}
+assertThrows(IllegalStateException.class, () -> iter.remove());
Review comment:
Ditto here...
##
File path:
src/test/java/org/apache/commons/collections4/iterators/ArrayListIteratorTest.java
##
@@ -104,15 +105,8 @@ public void testListIteratorSet() {
// a call to set() before a call to next() or previous() should throw
an IllegalStateException
iter = makeArrayListIterator(testArray);
-try {
-iter.set((E) "should fail");
-fail("ListIterator#set should fail if next() or previous() have
not yet been called.");
-} catch (final IllegalStateException e) {
-// expected
-} catch (final Throwable t) { // should never happen
-fail(t.toString());
-}
-
+ListIterator finalIter = iter;
+assertThrows(IllegalStateException.class, () -> finalIter.set((E)
"should fail"));
Review comment:
Would be good to preserve this error message too, IMO.
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionTest.java
##
@@ -99,12 +98,9 @@ public void testIllegalAddAll() {
elements.add((E) "two");
elements.add((E) Integer.valueOf(3));
elements.add((E) "four");
-try {
-c.addAll(elements);
-fail("Integer should fail string predicate.");
-} catch (final IllegalArgumentException e) {
-// expected
-}
+
+assertThrows(IllegalArgumentException.class, () -> c.addAll(elements));
Review comment:
Maybe keep the `fail` message here.
##
File path:
src/test/java/org/apache/commons/collections4/iterators/ListIteratorWrapper2Test.java
##
@@ -134,11 +131,7 @@ public void testRemove() {
assertEquals(-1, iter.previousIndex());
assertEquals(0, iter.nextIndex());
-try {
-iter.remove();
-fail("ListIteratorWrapper#remove() should fail; must be
repositioned first");
-} catch (final IllegalStateException e) {
-}
+assertThrows(IllegalStateException.class, () -> iter.remove());
Review comment:
And here...
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionTest.java
##
@@ -82,12 +84,9 @@ public PredicatedCollectionTest(final String name) {
public void testIllegalAdd() {
final Collection c = makeTestCollection();
final Integer i = 3;
-try {
-c.add((E) i);
-fail("Integer should fail string predicate.");
-} catch (final IllegalArgumentException e) {
-// expected
-}
+
+assertThrows(IllegalArgumentException.class, () -> c.add((E) i));
Review comment:
Maybe keep the `fail` message here.
##
File path:
src/test/java/org/apache/commons/collections4/iterators/ObjectArrayListIteratorTest.java
##
@@ -101,15 +102,8 @@ public void testListIteratorSet() {
// a call to set() before a call to next() or previous() should throw
an IllegalStateException
iter = makeArrayListIterator((E[]) testArray);
-try {
-iter.set((E) "should fail");
-fail("ListIterator#set should fail if next() or previous() have
not yet been called.");
-} catch (final IllegalStateException e) {
-// expected
-} catch (final Throwable t) { // should never happen
-fail(t.toString());
-}
-
+ListIterator finalIter = iter;
+assertThrows(IllegalStateException.class, () -> finalIter.set((E)
"should
[GitHub] [commons-collections] nhojpatrick commented on pull request #282: JUnit v5 assertThrows no2
nhojpatrick commented on pull request #282: URL: https://github.com/apache/commons-collections/pull/282#issuecomment-1057396171 Same type of work as #281 covered by COLLECTIONS-777 and have also squashed and prefixed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] nhojpatrick commented on pull request #281: JUnit v5 assertThrows
nhojpatrick commented on pull request #281: URL: https://github.com/apache/commons-collections/pull/281#issuecomment-1057394398 Was unaware of COLLECTIONS-777 but yes that would cover this work. I've squashed myself and prefixed commit with COLLECTIONS-777. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (EMAIL-201) gitmail.github.com
[ https://issues.apache.org/jira/browse/EMAIL-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed EMAIL-201. - Spam > gitmail.github.com > -- > > Key: EMAIL-201 > URL: https://issues.apache.org/jira/browse/EMAIL-201 > Project: Commons Email > Issue Type: Test >Reporter: Shafiul islam mahbub >Priority: Major > > Common email service and email server with developer hub > https://gitmail.github.com update GitHub docs docs.github.com/gitmail -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (EMAIL-201) gitmail.github.com
[ https://issues.apache.org/jira/browse/EMAIL-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory deleted EMAIL-201: -- > gitmail.github.com > -- > > Key: EMAIL-201 > URL: https://issues.apache.org/jira/browse/EMAIL-201 > Project: Commons Email > Issue Type: Test >Reporter: Shafiul islam mahbub >Priority: Major > > Common email service and email server with developer hub > https://gitmail.github.com update GitHub docs docs.github.com/gitmail -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (EMAIL-201) gitmail.github.com
Shafiul islam mahbub created EMAIL-201: -- Summary: gitmail.github.com Key: EMAIL-201 URL: https://issues.apache.org/jira/browse/EMAIL-201 Project: Commons Email Issue Type: Test Reporter: Shafiul islam mahbub Common email service and email server with developer hub https://gitmail.github.com update GitHub docs docs.github.com/gitmail -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-imaging] kinow merged pull request #205: Bump actions/checkout from 2.4.0 to 3
kinow merged pull request #205: URL: https://github.com/apache/commons-imaging/pull/205 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] coveralls commented on pull request #205: Bump actions/checkout from 2.4.0 to 3
coveralls commented on pull request #205: URL: https://github.com/apache/commons-imaging/pull/205#issuecomment-1057193172 [](https://coveralls.io/builds/47019605) Coverage remained the same at 76.865% when pulling **9fc2f76158be5879b03840580eb45f33f7d0cfa5 on dependabot/github_actions/actions/checkout-3** into **93a1aa3c30ed63fdbedbcf17f85eb35a96ff8703 on master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-exec] dependabot[bot] opened a new pull request #46: Bump actions/checkout from 2 to 3
dependabot[bot] opened a new pull request #46: URL: https://github.com/apache/commons-exec/pull/46 Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. Release notes Sourced from https://github.com/actions/checkout/releases;>actions/checkout's releases. v3.0.0 Update default runtime to node16 v2.4.0 Convert SSH URLs like org-ORG_ID@github.com: to https://github.com/ - https://github-redirect.dependabot.com/actions/checkout/pull/621;>pr v2.3.5 Update dependencies v2.3.4 https://github-redirect.dependabot.com/actions/checkout/pull/379;>Add missing awaits https://github-redirect.dependabot.com/actions/checkout/pull/360;>Swap to Environment Files v2.3.3 https://github-redirect.dependabot.com/actions/checkout/pull/345;>Remove Unneeded commit information from build logs https://github-redirect.dependabot.com/actions/checkout/pull/326;>Add Licensed to verify third party dependencies v2.3.2 https://github-redirect.dependabot.com/actions/checkout/pull/320;>Add Third Party License Information to Dist Files v2.3.1 https://github-redirect.dependabot.com/actions/checkout/pull/284;>Fix default branch resolution for .wiki and when using SSH v2.3.0 https://github-redirect.dependabot.com/actions/checkout/pull/278;>Fallback to the default branch v2.2.0 https://github-redirect.dependabot.com/actions/checkout/pull/258;>Fetch all history for all tags and branches when fetch-depth=0 v2.1.1 Changes to support GHES (https://github-redirect.dependabot.com/actions/checkout/pull/236;>here and https://github-redirect.dependabot.com/actions/checkout/pull/248;>here) v2.1.0 https://github-redirect.dependabot.com/actions/checkout/pull/191;>Group output https://github-redirect.dependabot.com/actions/checkout/pull/199;>Changes to support GHES alpha release https://github-redirect.dependabot.com/actions/checkout/pull/184;>Persist core.sshCommand for submodules https://github-redirect.dependabot.com/actions/checkout/pull/163;>Add support ssh https://github-redirect.dependabot.com/actions/checkout/pull/179;>Convert submodule SSH URL to HTTPS, when not using SSH https://github-redirect.dependabot.com/actions/checkout/pull/157;>Add submodule support https://github-redirect.dependabot.com/actions/checkout/pull/144;>Follow proxy settings https://github-redirect.dependabot.com/actions/checkout/pull/141;>Fix ref for pr closed event when a pr is merged https://github-redirect.dependabot.com/actions/checkout/pull/128;>Fix issue checking detached when git less than 2.22 Changelog Sourced from https://github.com/actions/checkout/blob/main/CHANGELOG.md;>actions/checkout's changelog. Changelog v2.3.1 https://github-redirect.dependabot.com/actions/checkout/pull/284;>Fix default branch resolution for .wiki and when using SSH v2.3.0 https://github-redirect.dependabot.com/actions/checkout/pull/278;>Fallback to the default branch v2.2.0 https://github-redirect.dependabot.com/actions/checkout/pull/258;>Fetch all history for all tags and branches when fetch-depth=0 v2.1.1 Changes to support GHES (https://github-redirect.dependabot.com/actions/checkout/pull/236;>here and https://github-redirect.dependabot.com/actions/checkout/pull/248;>here) v2.1.0 https://github-redirect.dependabot.com/actions/checkout/pull/191;>Group output https://github-redirect.dependabot.com/actions/checkout/pull/199;>Changes to support GHES alpha release https://github-redirect.dependabot.com/actions/checkout/pull/184;>Persist core.sshCommand for submodules https://github-redirect.dependabot.com/actions/checkout/pull/163;>Add support ssh https://github-redirect.dependabot.com/actions/checkout/pull/179;>Convert submodule SSH URL to HTTPS, when not using SSH https://github-redirect.dependabot.com/actions/checkout/pull/157;>Add submodule support https://github-redirect.dependabot.com/actions/checkout/pull/144;>Follow proxy settings https://github-redirect.dependabot.com/actions/checkout/pull/141;>Fix ref for pr closed event when a pr is merged https://github-redirect.dependabot.com/actions/checkout/pull/128;>Fix issue checking detached when git less than 2.22 v2.0.0 https://github-redirect.dependabot.com/actions/checkout/pull/108;>Do not pass cred on command line https://github-redirect.dependabot.com/actions/checkout/pull/107;>Add input persist-credentials https://github-redirect.dependabot.com/actions/checkout/pull/104;>Fallback to REST API to download repo v2 (beta) Improved fetch performance The default behavior now fetches only the SHA being checked-out Script authenticated git commands Persists with.token in the local git config Enables your scripts to run authenticated git commands Post-job
[GitHub] [commons-imaging] dependabot[bot] opened a new pull request #205: Bump actions/checkout from 2.4.0 to 3
dependabot[bot] opened a new pull request #205: URL: https://github.com/apache/commons-imaging/pull/205 Bumps [actions/checkout](https://github.com/actions/checkout) from 2.4.0 to 3. Release notes Sourced from https://github.com/actions/checkout/releases;>actions/checkout's releases. v3.0.0 Update default runtime to node16 Changelog Sourced from https://github.com/actions/checkout/blob/main/CHANGELOG.md;>actions/checkout's changelog. Changelog v2.3.1 https://github-redirect.dependabot.com/actions/checkout/pull/284;>Fix default branch resolution for .wiki and when using SSH v2.3.0 https://github-redirect.dependabot.com/actions/checkout/pull/278;>Fallback to the default branch v2.2.0 https://github-redirect.dependabot.com/actions/checkout/pull/258;>Fetch all history for all tags and branches when fetch-depth=0 v2.1.1 Changes to support GHES (https://github-redirect.dependabot.com/actions/checkout/pull/236;>here and https://github-redirect.dependabot.com/actions/checkout/pull/248;>here) v2.1.0 https://github-redirect.dependabot.com/actions/checkout/pull/191;>Group output https://github-redirect.dependabot.com/actions/checkout/pull/199;>Changes to support GHES alpha release https://github-redirect.dependabot.com/actions/checkout/pull/184;>Persist core.sshCommand for submodules https://github-redirect.dependabot.com/actions/checkout/pull/163;>Add support ssh https://github-redirect.dependabot.com/actions/checkout/pull/179;>Convert submodule SSH URL to HTTPS, when not using SSH https://github-redirect.dependabot.com/actions/checkout/pull/157;>Add submodule support https://github-redirect.dependabot.com/actions/checkout/pull/144;>Follow proxy settings https://github-redirect.dependabot.com/actions/checkout/pull/141;>Fix ref for pr closed event when a pr is merged https://github-redirect.dependabot.com/actions/checkout/pull/128;>Fix issue checking detached when git less than 2.22 v2.0.0 https://github-redirect.dependabot.com/actions/checkout/pull/108;>Do not pass cred on command line https://github-redirect.dependabot.com/actions/checkout/pull/107;>Add input persist-credentials https://github-redirect.dependabot.com/actions/checkout/pull/104;>Fallback to REST API to download repo v2 (beta) Improved fetch performance The default behavior now fetches only the SHA being checked-out Script authenticated git commands Persists with.token in the local git config Enables your scripts to run authenticated git commands Post-job cleanup removes the token Coming soon: Opt out by setting with.persist-credentials to false Creates a local branch No longer detached HEAD when checking out a branch A local branch is created with the corresponding upstream branch set Improved layout ... (truncated) Commits https://github.com/actions/checkout/commit/a12a3943b4bdde767164f792f33f40b04645d846;>a12a394 update readme for v3 (https://github-redirect.dependabot.com/actions/checkout/issues/708;>#708) https://github.com/actions/checkout/commit/8f9e05e482293f862823fcca12d9eddfb3723131;>8f9e05e Update to node 16 (https://github-redirect.dependabot.com/actions/checkout/issues/689;>#689) https://github.com/actions/checkout/commit/230611dbd0eb52da1e1f4f7bc8bb0c3a339fc8b7;>230611d Change secret name for PAT to not start with GITHUB_ (https://github-redirect.dependabot.com/actions/checkout/issues/623;>#623) See full diff in https://github.com/actions/checkout/compare/v2.4.0...v3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same
[GitHub] [commons-collections] nhojpatrick commented on pull request #282: JUnit v5 assertThrows no2
nhojpatrick commented on pull request #282: URL: https://github.com/apache/commons-collections/pull/282#issuecomment-1056609939 Something has gone wrong, will fix later -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] nhojpatrick opened a new pull request #282: JUnit v5 assertThrows no2
nhojpatrick opened a new pull request #282: URL: https://github.com/apache/commons-collections/pull/282 Another set of changed, should not have merge conflicts with other PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-fileupload] jochenw merged pull request #138: Bump actions/checkout from 2 to 3
jochenw merged pull request #138: URL: https://github.com/apache/commons-fileupload/pull/138 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
