[lang][LANG-1172] Back and forth on LocaleUtils.toLocale()
Hi All, Following up on this as LANG-1172 changed the previously declared contract of this method. Prior to 2.13, the logic and javadocs clearly stated that the separator must be underscore, but with this change it now also excepts dash. Javadocs from 2.12: "This method validates the input strictly. The language code must be lowercase. The country code must be uppercase. The separator must be an underscore. The length must be correct.” This changed the contract and breaks code that were previous using this method to verify that their locale strings did not have dash, which was sometimes done to differentiate between locales and language tags. However, the new behavior implies that locales and language tags are fully interchangeable, which is also not the case. While I agree it would be useful to have a method that supported conversion of both representations, it would be better to provide that as a new method rather than break the existing contract. TY Josh Gary D. Gregory - Wednesday, September 4, 2024 6:51:00 AM PDT [lang][LANG-1172] Back and forth on LocaleUtils.toLocale() Hi All, I'd like to settle on the implementation of LocaleUtils.toLocale() one way or another and clearly document expectations. What should we do? Please see: - https://issues.apache.org/jira/browse/LANG-1172 - https://github.com/apache/commons-lang/pull/766 - https://github.com/apache/commons-lang/pull/1271 TY! Gary
[lang][LANG-1172] Back and forth on LocaleUtils.toLocale()
Hi All, I'd like to settle on the implementation of LocaleUtils.toLocale() one way or another and clearly document expectations. What should we do? Please see: - https://issues.apache.org/jira/browse/LANG-1172 - https://github.com/apache/commons-lang/pull/766 - https://github.com/apache/commons-lang/pull/1271 TY! Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Apache Commons Lang 3.17.0
The Apache Commons team is pleased to announce Apache Commons Lang Version 3.17.0. Commons Lang is a set of utility functions and reusable components that should be useful in any Java environment. Starting with Commons Lang 3.9, we target Java 8, using those features. For advice on upgrading from 2.x to 3.x, see: https://commons.apache.org/lang/article3_0.html Apache Commons Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in java.lang. The code is tested using the latest revision of the JDK for supported LTS releases: 8, 11, 17 and 21 currently. See https://github.com/apache/commons-lang/blob/master/.github/workflows/maven.yml Please ensure your build environment is up-to-date and kindly report any build issues. This is a feature and maintenance release. Java 8 or later is required. Historical list of changes: https://commons.apache.org/proper/commons-lang/changes-report.html For complete information on Apache Commons Lang, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Lang website: https://commons.apache.org/proper/commons-lang/ Download page: https://commons.apache.org/proper/commons-lang/download_lang.cgi Gary Gregory, Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Release Apache Commons Lang 3.17.0 based on RC1
This vote passes with the following binding +1s: - Gary Gregory (ggregory) - Henri Biestro (henrib) - Rob Tompkins (chtompki) TY all, Gary On Thu, Aug 29, 2024 at 1:57 PM Rob Tompkins wrote: > > +1 > > > On Aug 24, 2024, at 3:21 PM, Gary Gregory wrote: > > > > We have fixed a few bugs and added enhancements since Apache Commons Lang > > 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0. > > > > Apache Commons Lang 3.17.0 RC1 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1 (svn > > revision 71083) > > > > The Git tag commons-lang-3.17.0-RC1 commit for this RC is > > 29ccc7665f3bc5d84155a3092ab2209a053324e6 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=29ccc7665f3bc5d84155a3092ab2209a053324e6 > > You may checkout this tag using: > >git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch > > commons-lang-3.17.0-RC1 commons-lang-3.17.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1777/org/apache/commons/commons-lang3/3.17.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Sat Aug 24 19:06:25 UTC 2024 > > commons-lang3-3.17.0-bin.tar.gz=8927a406a1bd084b548f89cf15fe4bc7567dcaa50ae8abae54e9c883c1574c648fcc8ad6c3abaa381dfbdf1801727ac5e6c4572063203a1dfac293d122282f05 > > commons-lang3-3.17.0-bin.zip=00ea810d00b0f8a5bf898edfed1fa022e9bd2bf31c9c00859de2ac6c4bc971d6833f3c2e0b24cecad6bb979de2078be8b1cc7eb42ca63c9ec35f70b1490e8c3d > > commons-lang3-3.17.0-bom.json=b39ff96546bccdcf8fd2547ba3c130988541a99557e08de4b99bae09c43be569bf1939cec9fdba65d54df890c80fe58ba72e5194f9adb26c00b3f497f7f04230 > > commons-lang3-3.17.0-bom.xml=973b469f1395cfd709f281878faaed610cde2a778e66609ccd76408a17718c5291e538f1fe1b09052b7042d0aa7bed1f38f39249b3e2c0ff374d3165d63b443b > > commons-lang3-3.17.0-javadoc.jar=64a1feec66688bb06486871a6a0bf3075d57efddad8fd36a1d540c88ac8e7c562cf5dbffd5c4e5155cbc808f10b8001210728719727fdc6d246a0536fdc60d35 > > commons-lang3-3.17.0-sources.jar=15954a47f38df821f97282d130c16e4885dcae16503e3876adc5518a3f6f7f3ecfa62b777b98b6ae11878e305f99ed28181c28f3369d4da2a3fb7c696d4be1d2 > > commons-lang3-3.17.0-src.tar.gz=e633b0caeb9556c68384c2bf20e374fbac910b9979b25774c632e50c1bec41e97c14362978dc092c8b5859291e54fe51e76ad7a61c9b2efbe1e4538f46c1e3ee > > commons-lang3-3.17.0-src.zip=7e715243fd2cd0464eadd5140949c751ae199b87f4f6db6a0b878fe3bcbc513e3a9603f7bc09a2251cb61b794843826f3ea9d5c21a7b3b5f78cae13ab7b10bed > > commons-lang3-3.17.0-test-sources.jar=bca1775e70313838191d530181ecf41ae832cb5bf041d2713af71e8b6d931307776ed9f10cf27a7f6f45a2b497a6ab717730e2a21605473eddb829738ca9e242 > > commons-lang3-3.17.0-tests.jar=b6138e9e92845ad790b2bbc43440ba16b92478700ee3f4e620b1fbb6d0796c2e110b53ab85f845d05a0d3e56f55417faf7eb01b15efe70339ccdf76ed3da76bc > > org.apache.commons_commons-lang3-3.17.0.spdx.json=b9ca110a8e4e5304091991db151ad64a43ddd6ac10c170b0759daa84565df333cee5cf8d85af2f600233c692b27b826858db1af1a0ab2add7fcb77a1f3c0 > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P > > jacoco -P japicmp clean package site deploy' using: > > > > openjdk version "17.0.12" 2024-07-16 > > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > > > Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) > > Maven home: /usr/local/Cellar/maven/3.9.9/libexec > > Java version: 17.0.12, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac" > > > > Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT > > 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.16.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/index.html > >(note some *relative* links are broken and the 3.17.0 directories are > > not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.16.0): > > > > https://dist.apache.
Re: [VOTE] Release Apache Commons Lang 3.17.0 based on RC1
+1 > On Aug 24, 2024, at 3:21 PM, Gary Gregory wrote: > > We have fixed a few bugs and added enhancements since Apache Commons Lang > 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0. > > Apache Commons Lang 3.17.0 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1 (svn > revision 71083) > > The Git tag commons-lang-3.17.0-RC1 commit for this RC is > 29ccc7665f3bc5d84155a3092ab2209a053324e6 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=29ccc7665f3bc5d84155a3092ab2209a053324e6 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch > commons-lang-3.17.0-RC1 commons-lang-3.17.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1777/org/apache/commons/commons-lang3/3.17.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Aug 24 19:06:25 UTC 2024 > commons-lang3-3.17.0-bin.tar.gz=8927a406a1bd084b548f89cf15fe4bc7567dcaa50ae8abae54e9c883c1574c648fcc8ad6c3abaa381dfbdf1801727ac5e6c4572063203a1dfac293d122282f05 > commons-lang3-3.17.0-bin.zip=00ea810d00b0f8a5bf898edfed1fa022e9bd2bf31c9c00859de2ac6c4bc971d6833f3c2e0b24cecad6bb979de2078be8b1cc7eb42ca63c9ec35f70b1490e8c3d > commons-lang3-3.17.0-bom.json=b39ff96546bccdcf8fd2547ba3c130988541a99557e08de4b99bae09c43be569bf1939cec9fdba65d54df890c80fe58ba72e5194f9adb26c00b3f497f7f04230 > commons-lang3-3.17.0-bom.xml=973b469f1395cfd709f281878faaed610cde2a778e66609ccd76408a17718c5291e538f1fe1b09052b7042d0aa7bed1f38f39249b3e2c0ff374d3165d63b443b > commons-lang3-3.17.0-javadoc.jar=64a1feec66688bb06486871a6a0bf3075d57efddad8fd36a1d540c88ac8e7c562cf5dbffd5c4e5155cbc808f10b8001210728719727fdc6d246a0536fdc60d35 > commons-lang3-3.17.0-sources.jar=15954a47f38df821f97282d130c16e4885dcae16503e3876adc5518a3f6f7f3ecfa62b777b98b6ae11878e305f99ed28181c28f3369d4da2a3fb7c696d4be1d2 > commons-lang3-3.17.0-src.tar.gz=e633b0caeb9556c68384c2bf20e374fbac910b9979b25774c632e50c1bec41e97c14362978dc092c8b5859291e54fe51e76ad7a61c9b2efbe1e4538f46c1e3ee > commons-lang3-3.17.0-src.zip=7e715243fd2cd0464eadd5140949c751ae199b87f4f6db6a0b878fe3bcbc513e3a9603f7bc09a2251cb61b794843826f3ea9d5c21a7b3b5f78cae13ab7b10bed > commons-lang3-3.17.0-test-sources.jar=bca1775e70313838191d530181ecf41ae832cb5bf041d2713af71e8b6d931307776ed9f10cf27a7f6f45a2b497a6ab717730e2a21605473eddb829738ca9e242 > commons-lang3-3.17.0-tests.jar=b6138e9e92845ad790b2bbc43440ba16b92478700ee3f4e620b1fbb6d0796c2e110b53ab85f845d05a0d3e56f55417faf7eb01b15efe70339ccdf76ed3da76bc > org.apache.commons_commons-lang3-3.17.0.spdx.json=b9ca110a8e4e5304091991db151ad64a43ddd6ac10c170b0759daa84565df333cee5cf8d85af2f600233c692b27b826858db1af1a0ab2add7fcb77a1f3c0 > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P > jacoco -P japicmp clean package site deploy' using: > > openjdk version "17.0.12" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) > Maven home: /usr/local/Cellar/maven/3.9.9/libexec > Java version: 17.0.12, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac" > > Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT > 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64 > > Details of changes since 3.16.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/index.html >(note some *relative* links are broken and the 3.17.0 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.16.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/japicmp.html > >*** >Note that the above report notes several errors. >These are considered OK for the reasons stated below. >These exceptions are also noted in the Changes and Release Notes. > >Errors reported: >- methods added to interface: OK because that does not affect binary > compatibility. >- etc. >*** > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/rat-repo
Re: [VOTE] Release Apache Commons Lang 3.17.0 based on RC1
[ +1 ] Build & tests ok, javadoc ok, reports look good (nice coverage), site looks nice. Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml" On: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "mac" - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.17.0 based on RC1
My +1 Gary On Sat, Aug 24, 2024 at 3:21 PM Gary Gregory wrote: > We have fixed a few bugs and added enhancements since Apache Commons Lang > 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0. > > Apache Commons Lang 3.17.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1 (svn > revision 71083) > > The Git tag commons-lang-3.17.0-RC1 commit for this RC is > 29ccc7665f3bc5d84155a3092ab2209a053324e6 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=29ccc7665f3bc5d84155a3092ab2209a053324e6 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch commons-lang-3.17.0-RC1 commons-lang-3.17.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1777/org/apache/commons/commons-lang3/3.17.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Aug 24 19:06:25 UTC 2024 > > commons-lang3-3.17.0-bin.tar.gz=8927a406a1bd084b548f89cf15fe4bc7567dcaa50ae8abae54e9c883c1574c648fcc8ad6c3abaa381dfbdf1801727ac5e6c4572063203a1dfac293d122282f05 > > commons-lang3-3.17.0-bin.zip=00ea810d00b0f8a5bf898edfed1fa022e9bd2bf31c9c00859de2ac6c4bc971d6833f3c2e0b24cecad6bb979de2078be8b1cc7eb42ca63c9ec35f70b1490e8c3d > > commons-lang3-3.17.0-bom.json=b39ff96546bccdcf8fd2547ba3c130988541a99557e08de4b99bae09c43be569bf1939cec9fdba65d54df890c80fe58ba72e5194f9adb26c00b3f497f7f04230 > > commons-lang3-3.17.0-bom.xml=973b469f1395cfd709f281878faaed610cde2a778e66609ccd76408a17718c5291e538f1fe1b09052b7042d0aa7bed1f38f39249b3e2c0ff374d3165d63b443b > > commons-lang3-3.17.0-javadoc.jar=64a1feec66688bb06486871a6a0bf3075d57efddad8fd36a1d540c88ac8e7c562cf5dbffd5c4e5155cbc808f10b8001210728719727fdc6d246a0536fdc60d35 > > commons-lang3-3.17.0-sources.jar=15954a47f38df821f97282d130c16e4885dcae16503e3876adc5518a3f6f7f3ecfa62b777b98b6ae11878e305f99ed28181c28f3369d4da2a3fb7c696d4be1d2 > > commons-lang3-3.17.0-src.tar.gz=e633b0caeb9556c68384c2bf20e374fbac910b9979b25774c632e50c1bec41e97c14362978dc092c8b5859291e54fe51e76ad7a61c9b2efbe1e4538f46c1e3ee > > commons-lang3-3.17.0-src.zip=7e715243fd2cd0464eadd5140949c751ae199b87f4f6db6a0b878fe3bcbc513e3a9603f7bc09a2251cb61b794843826f3ea9d5c21a7b3b5f78cae13ab7b10bed > > commons-lang3-3.17.0-test-sources.jar=bca1775e70313838191d530181ecf41ae832cb5bf041d2713af71e8b6d931307776ed9f10cf27a7f6f45a2b497a6ab717730e2a21605473eddb829738ca9e242 > > commons-lang3-3.17.0-tests.jar=b6138e9e92845ad790b2bbc43440ba16b92478700ee3f4e620b1fbb6d0796c2e110b53ab85f845d05a0d3e56f55417faf7eb01b15efe70339ccdf76ed3da76bc > > org.apache.commons_commons-lang3-3.17.0.spdx.json=b9ca110a8e4e5304091991db151ad64a43ddd6ac10c170b0759daa84565df333cee5cf8d85af2f600233c692b27b826858db1af1a0ab2add7fcb77a1f3c0 > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P > jacoco -P japicmp clean package site deploy' using: > > openjdk version "17.0.12" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) > Maven home: /usr/local/Cellar/maven/3.9.9/libexec > Java version: 17.0.12, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac" > > Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT > 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64 > > Details of changes since 3.16.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/index.html > (note some *relative* links are broken and the 3.17.0 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.16.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/japicmp.html > > *** > Note that the above report notes several errors. > These are considered OK for the reasons stated below. > These exceptions are also noted in the Changes and Release Notes. > > Errors reported: > - methods added to interface: OK because that does not affect binary > compatibility. > - etc. > *** > > RAT Report: > > https://dist.apache.org/repos
[VOTE] Release Apache Commons Lang 3.17.0 based on RC1
We have fixed a few bugs and added enhancements since Apache Commons Lang
3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0.
Apache Commons Lang 3.17.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1 (svn
revision 71083)
The Git tag commons-lang-3.17.0-RC1 commit for this RC is
29ccc7665f3bc5d84155a3092ab2209a053324e6 which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=29ccc7665f3bc5d84155a3092ab2209a053324e6
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch
commons-lang-3.17.0-RC1 commons-lang-3.17.0-RC1
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1777/org/apache/commons/commons-lang3/3.17.0/
These are the artifacts and their hashes:
#Release SHA-512s
#Sat Aug 24 19:06:25 UTC 2024
commons-lang3-3.17.0-bin.tar.gz=8927a406a1bd084b548f89cf15fe4bc7567dcaa50ae8abae54e9c883c1574c648fcc8ad6c3abaa381dfbdf1801727ac5e6c4572063203a1dfac293d122282f05
commons-lang3-3.17.0-bin.zip=00ea810d00b0f8a5bf898edfed1fa022e9bd2bf31c9c00859de2ac6c4bc971d6833f3c2e0b24cecad6bb979de2078be8b1cc7eb42ca63c9ec35f70b1490e8c3d
commons-lang3-3.17.0-bom.json=b39ff96546bccdcf8fd2547ba3c130988541a99557e08de4b99bae09c43be569bf1939cec9fdba65d54df890c80fe58ba72e5194f9adb26c00b3f497f7f04230
commons-lang3-3.17.0-bom.xml=973b469f1395cfd709f281878faaed610cde2a778e66609ccd76408a17718c5291e538f1fe1b09052b7042d0aa7bed1f38f39249b3e2c0ff374d3165d63b443b
commons-lang3-3.17.0-javadoc.jar=64a1feec66688bb06486871a6a0bf3075d57efddad8fd36a1d540c88ac8e7c562cf5dbffd5c4e5155cbc808f10b8001210728719727fdc6d246a0536fdc60d35
commons-lang3-3.17.0-sources.jar=15954a47f38df821f97282d130c16e4885dcae16503e3876adc5518a3f6f7f3ecfa62b777b98b6ae11878e305f99ed28181c28f3369d4da2a3fb7c696d4be1d2
commons-lang3-3.17.0-src.tar.gz=e633b0caeb9556c68384c2bf20e374fbac910b9979b25774c632e50c1bec41e97c14362978dc092c8b5859291e54fe51e76ad7a61c9b2efbe1e4538f46c1e3ee
commons-lang3-3.17.0-src.zip=7e715243fd2cd0464eadd5140949c751ae199b87f4f6db6a0b878fe3bcbc513e3a9603f7bc09a2251cb61b794843826f3ea9d5c21a7b3b5f78cae13ab7b10bed
commons-lang3-3.17.0-test-sources.jar=bca1775e70313838191d530181ecf41ae832cb5bf041d2713af71e8b6d931307776ed9f10cf27a7f6f45a2b497a6ab717730e2a21605473eddb829738ca9e242
commons-lang3-3.17.0-tests.jar=b6138e9e92845ad790b2bbc43440ba16b92478700ee3f4e620b1fbb6d0796c2e110b53ab85f845d05a0d3e56f55417faf7eb01b15efe70339ccdf76ed3da76bc
org.apache.commons_commons-lang3-3.17.0.spdx.json=b9ca110a8e4e5304091991db151ad64a43ddd6ac10c170b0759daa84565df333cee5cf8d85af2f600233c692b27b826858db1af1a0ab2add7fcb77a1f3c0
I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P
jacoco -P japicmp clean package site deploy' using:
openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment Homebrew (build 17.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing)
Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /usr/local/Cellar/maven/3.9.9/libexec
Java version: 17.0.12, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac"
Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT
2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64
Details of changes since 3.16.0 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/changes-report.html
Site:
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/index.html
(note some *relative* links are broken and the 3.17.0 directories are
not yet created - these will be OK once the site is deployed.)
JApiCmp Report (compared to 3.16.0):
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/japicmp.html
***
Note that the above report notes several errors.
These are considered OK for the reasons stated below.
These exceptions are also noted in the Changes and Release Notes.
Errors reported:
- methods added to interface: OK because that does not affect binary
compatibility.
- etc.
***
RAT Report:
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1/site/rat-report.html
KEYS:
https://downloads.apache.org/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)
The following is intended as a helper and refresher for reviewers.
Validating a release candi
Re: [LANG] LANG-1747: Measure the execution time of functional interfaces #1254
Hello all, Whichever names we pick if we accept the contribution, I think it is best to look at the method names in context, not standalone. For example, you would "say": stopWatch.accept(x -> ...) and so on. I find it simpler to match the new names with the delegate but YMMV ;-) All the names should be consistent in some way. IOW, ALL method names could be - stopWatch.add(...), or - stopWatch.time(...), or - ... Wdyt? Gary On Sat, Aug 17, 2024, 2:55 PM Peter Burka wrote: > I think this is a useful addition, but I wonder if these new APIs are > misnamed: StopWatch::test doesn't actually test, nor does StopWatch::accept > consume. Instead, these all wrap lambdas in a timed version of the same > type. (There's probably some lambda calculus terminology for this.) > > I'd propose renaming all of the functional interface-wrapping functions to > use a single, overloaded name, e.g. StopWatch::timed(...) or > StopWatch::withTiming(...) > > /peter > > On Fri, Aug 16, 2024, 10:50 PM Gary Gregory > wrote: > > > Hi all, > > > > Please provide any feedback on > > - LANG-1747: Measure the execution time of functional interfaces #1254 > > - https://github.com/apache/commons-lang/pull/1254/ > > TY! > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [LANG] LANG-1747: Measure the execution time of functional interfaces #1254
I think this is a useful addition, but I wonder if these new APIs are misnamed: StopWatch::test doesn't actually test, nor does StopWatch::accept consume. Instead, these all wrap lambdas in a timed version of the same type. (There's probably some lambda calculus terminology for this.) I'd propose renaming all of the functional interface-wrapping functions to use a single, overloaded name, e.g. StopWatch::timed(...) or StopWatch::withTiming(...) /peter On Fri, Aug 16, 2024, 10:50 PM Gary Gregory wrote: > Hi all, > > Please provide any feedback on > - LANG-1747: Measure the execution time of functional interfaces #1254 > - https://github.com/apache/commons-lang/pull/1254/ > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[LANG] LANG-1747: Measure the execution time of functional interfaces #1254
Hi all, Please provide any feedback on - LANG-1747: Measure the execution time of functional interfaces #1254 - https://github.com/apache/commons-lang/pull/1254/ TY! Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Thoughs on merging PR "Support generation of single quotes #1227"
Hi All, I'd like some thoughts on merging https://github.com/apache/commons-lang/pull/1227 It seems OK to me. Anyone else? TY! Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Apache Commons Lang Version 3.16.0
The Apache Commons team is pleased to announce Apache Commons Lang Version 3.16.0. Commons Lang is a set of utility functions and reusable components that should be useful in any Java environment. Starting with Commons Lang 3.9, we target Java 8, using those features. For advice on upgrading from 2.x to 3.x, see: https://commons.apache.org/lang/article3_0.html Apache Commons Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in java.lang. The code is tested using the latest revision of the JDK for supported LTS releases: 8, 11, 17 and 21 currently. See https://github.com/apache/commons-lang/blob/master/.github/workflows/maven.yml Please ensure your build environment is up-to-date and kindly report any build issues. This is a feature and maintenance release. Java 8 or later is required. Historical list of changes: https://commons.apache.org/proper/commons-lang/changes-report.html For complete information on Apache Commons Lang, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Lang website: https://commons.apache.org/proper/commons-lang/ Download page: https://commons.apache.org/proper/commons-lang/download_lang.cgi Have fun! Gary Gregory Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.16.0 based on RC1
This vote thread passes with the following +1 votes: - Rob Tompkins (chtompki, binding) - Tomas Lanik (non-binding) - Gary Gregory (ggregory, binding) - Bruno Kinoshita (kinow, binding) Gary On Wed, Aug 7, 2024 at 11:11 AM Bruno P. Kinoshita wrote: > > +1 > > Build passing on > > Apache Maven 3.8.7 > Maven home: /usr/share/maven > Java version: 17.0.12, vendor: Ubuntu, runtime: > /usr/lib/jvm/java-17-openjdk-amd64 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.8.0-39-generic", arch: "amd64", family: "unix" > > Thanks!!! > > On 2024/08/01 12:34:55 Gary Gregory wrote: > > We have fixed a few bugs and added enhancements since Apache Commons > > Lang 3.15.0 was released, so I would like to release Apache Commons > > Lang 3.16.0. > > > > Apache Commons Lang 3.16.0 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 > > (svn revision 70651) > > > > The Git tag commons-lang-3.16.0-RC1 commit for this RC is > > 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > > --branch commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Thu Aug 01 12:24:25 UTC 2024 > > commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 > > commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 > > commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 > > commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 > > commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 > > commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 > > commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c > > commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 > > commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b > > commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 > > org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > > -P jacoco -P japicmp clean package site deploy' using: > > > > openjdk version "21.0.4" 2024-07-16 > > OpenJDK Runtime Environment Homebrew (build 21.0.4) > > OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) > > > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > > Java version: 21.0.4, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.15.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/d
Re: [VOTE] Release Apache Commons Lang 3.16.0 based on RC1
+1 Build passing on Apache Maven 3.8.7 Maven home: /usr/share/maven Java version: 17.0.12, vendor: Ubuntu, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.8.0-39-generic", arch: "amd64", family: "unix" Thanks!!! On 2024/08/01 12:34:55 Gary Gregory wrote: > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.15.0 was released, so I would like to release Apache Commons > Lang 3.16.0. > > Apache Commons Lang 3.16.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 > (svn revision 70651) > > The Git tag commons-lang-3.16.0-RC1 commit for this RC is > 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Thu Aug 01 12:24:25 UTC 2024 > commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 > commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 > commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 > commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 > commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 > commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 > commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c > commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 > commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b > commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 > org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy' using: > > openjdk version "21.0.4" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 21.0.4) > OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 21.0.4, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.15.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/index.html > (note some *relative* links are broken and the 3.16.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.15.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/rat-report.html > > KEYS:
Re: [VOTE] Release Apache Commons Lang 3.16.0 based on RC1
My +1 Gary On Fri, Aug 2, 2024 at 11:17 AM Rob Tompkins wrote: > > +1 all looks good to me. > > Thanks Gary! > > -Rob > > > On Aug 1, 2024, at 8:34 AM, Gary Gregory wrote: > > > > We have fixed a few bugs and added enhancements since Apache Commons > > Lang 3.15.0 was released, so I would like to release Apache Commons > > Lang 3.16.0. > > > > Apache Commons Lang 3.16.0 RC1 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 > > (svn revision 70651) > > > > The Git tag commons-lang-3.16.0-RC1 commit for this RC is > > 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 > > You may checkout this tag using: > >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > > --branch commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Thu Aug 01 12:24:25 UTC 2024 > > commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 > > commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 > > commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 > > commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 > > commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 > > commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 > > commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c > > commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 > > commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b > > commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 > > org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > > -P jacoco -P japicmp clean package site deploy' using: > > > > openjdk version "21.0.4" 2024-07-16 > > OpenJDK Runtime Environment Homebrew (build 21.0.4) > > OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) > > > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > > Java version: 21.0.4, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.15.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/index.html > >(note some *relative* links are broken and the 3.16.0 directories > > are not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.15.0): > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/j
Re: [VOTE] Release Apache Commons Lang 3.16.0 based on RC1
[+1] Thank you! Tomas Lanik On Thu, Aug 1, 2024, 14:35 Gary Gregory wrote: > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.15.0 was released, so I would like to release Apache Commons > Lang 3.16.0. > > Apache Commons Lang 3.16.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 > (svn revision 70651) > > The Git tag commons-lang-3.16.0-RC1 commit for this RC is > 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch <https://gitbox.apache.org/repos/asf/commons-lang.git--branch> > commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Thu Aug 01 12:24:25 UTC 2024 > > commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 > > commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 > > commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 > > commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 > > commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 > > commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 > > commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c > > commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 > > commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b > > commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 > > org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy' using: > > openjdk version "21.0.4" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 21.0.4) > OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 21.0.4, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.15.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/index.html > (note some *relative* links are broken and the 3.16.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.15.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ]
Re: [VOTE] Release Apache Commons Lang 3.16.0 based on RC1
+1 all looks good to me. Thanks Gary! -Rob > On Aug 1, 2024, at 8:34 AM, Gary Gregory wrote: > > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.15.0 was released, so I would like to release Apache Commons > Lang 3.16.0. > > Apache Commons Lang 3.16.0 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 > (svn revision 70651) > > The Git tag commons-lang-3.16.0-RC1 commit for this RC is > 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Thu Aug 01 12:24:25 UTC 2024 > commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 > commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 > commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 > commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 > commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 > commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 > commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c > commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 > commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b > commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 > org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy' using: > > openjdk version "21.0.4" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 21.0.4) > OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 21.0.4, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.15.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/index.html >(note some *relative* links are broken and the 3.16.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.15.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1
[VOTE] Release Apache Commons Lang 3.16.0 based on RC1
We have fixed a few bugs and added enhancements since Apache Commons Lang 3.15.0 was released, so I would like to release Apache Commons Lang 3.16.0. Apache Commons Lang 3.16.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1 (svn revision 70651) The Git tag commons-lang-3.16.0-RC1 commit for this RC is 6a2a10d5343cfe37c1d9fa42ac5edda7cab5 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=6a2a10d5343cfe37c1d9fa42ac5edda7cab5 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-lang-3.16.0-RC1 commons-lang-3.16.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1763/org/apache/commons/commons-lang3/3.16.0/ These are the artifacts and their hashes: #Release SHA-512s #Thu Aug 01 12:24:25 UTC 2024 commons-lang3-3.16.0-bin.tar.gz=b028d890edf7e0538461dc325ca7767ae3dd292654ccb2d12560c39ee84e03b9b4304ac49b59a710dbf2dcb21ee605b6737508fc115ca2c92b8320500ab7fac8 commons-lang3-3.16.0-bin.zip=c10231ed795bd1747a323805b4cbf294e8eb9176404815d4ac8e65d8792141feed33393adbdbd9e732c9802de3934bad72a19fd69f80976460f52660fe21 commons-lang3-3.16.0-bom.json=322bbac48672ac1fe0fe7e6a2cc91e294dd2c09a4e48122cbb9ce2fbe94964dae0c123316d928b5b9d17397028fc500a4f01ce151ea083002b26fc423177b262 commons-lang3-3.16.0-bom.xml=3ae1b75ea4e3242188c68c001a0f869a7bfdb0ba0a031c619f586471cd2c2020eb3639dbe65295f34956b97302bfe2c249b95af9f1c4c1ab5fd8fcd342745187 commons-lang3-3.16.0-javadoc.jar=5b5301e46b70a23c4fd6b957f86321232bbfe354b9334be0423f497d5714dfb12f4ee1be6b4a8d232c01c6ed4bfeb052494127ce9de311b9b52cebea5c908ec8 commons-lang3-3.16.0-sources.jar=b3c71e990f4aeaaba099d8d7e50d44d142641b6f6f594476c873b5132062bc6b450dcd3a5a8fa42dde2813f9f9e7d6b72d5d49c3b04e2654f4b65981ffa696c6 commons-lang3-3.16.0-src.tar.gz=f9b36642d6b31b94cd6f32fcdf9364910ccea06dd331f3aa4e474a42d496b9d9f1fb1375f92e563125ecb0dce71d5cccbc4c9965edf7ab8136df272bc03d126c commons-lang3-3.16.0-src.zip=9be57e0814e8e0b59b759ab0ddc538d4a7bfcccfb5fe2bf9c817b68df8b85319c55b76549f5c92b41da383f29442c03e1a6bcd8ccd2f3cf8129d43938ffca363 commons-lang3-3.16.0-test-sources.jar=051952f32fd7d51dba5aa3be67bc997d6ca1f316f780af70e807ac43419cb68d700890ab4e474904deb5b136ca683a8aa91bba5f108d7de1a0363ceccea10f4b commons-lang3-3.16.0-tests.jar=4b0147a3a8d0214bf798eb3e52499be9d02f0cb2639d93877217d4b1a76cc394a887213b2043eea3ceeb26659b1298c28c93605f43d8039f10adf9fbfa8d2c49 org.apache.commons_commons-lang3-3.16.0.spdx.json=ff9c6d85b84fa97173574a4484f9cb8ff3a8b1e0d2ce49bc303b633bfc03b8c2112454e02c88268042b46a2f81ce48030d323aa42bd8f8da12cdcb88082c9ed4 I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: openjdk version "21.0.4" 2024-07-16 OpenJDK Runtime Environment Homebrew (build 21.0.4) OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /usr/local/Cellar/maven/3.9.8/libexec Java version: 21.0.4, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 Details of changes since 3.15.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/index.html (note some *relative* links are broken and the 3.16.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.15.0): https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) The following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-lang-3.16.
[ANNOUNCE] Apache Commons Lang Version 3.15.0
The Apache Commons team is pleased to announce Apache Commons Lang Version 3.15.0. Commons Lang is a set of utility functions and reusable components that should be useful in any Java environment. Starting with Commons Lang 3.9, we target Java 8, using those features. For advice on upgrading from 2.x to 3.x, see: https://commons.apache.org/lang/article3_0.html Apache Commons Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in java.lang. The code is tested using the latest revision of the JDK for supported LTS releases: 8, 11, 17 and 21 currently. See https://github.com/apache/commons-lang/blob/master/.github/workflows/maven.yml Please ensure your build environment is up-to-date and kindly report any build issues. Historical list of changes: https://commons.apache.org/proper/commons-lang/changes-report.html For complete information on Apache Commons Lang, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Lang website: https://commons.apache.org/proper/commons-lang/ Download page: https://commons.apache.org/proper/commons-lang/download_lang.cgi Have fun! Gary Gregory Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Release Apache Commons Lang 3.15.0 based on RC2
This vote passes with the following votes: - Gary Gregory (ggregory, binding) - Tomas Lanik (non-binding) - Rob Tompkins (chtompki, binding) - Henri Biestro (henrib, binding) Gary On Wed, Jul 17, 2024 at 2:17 PM Henri Biestro wrote: > > [ +1 ] > > Builds and tests ok; site and Javadoc look good, reports are ok (commendable > coverage btw, nit JIRA report with no version and Tag List report shows a lot > of todo/fixme/etc). > > Built using: mvn -P jacoco -P japicmp clean install site -s > ~/.m2/commons-settings.xml > With JDK: > openjdk version "21.0.3" 2024-04-16 LTS > OpenJDK Runtime Environment Zulu21.34+19-CA (build 21.0.3+9-LTS) > OpenJDK 64-Bit Server VM Zulu21.34+19-CA (build 21.0.3+9-LTS, mixed mode, > sharing) > And maven: > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 > Java version: 21.0.3, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac" > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC2
[ +1 ] Builds and tests ok; site and Javadoc look good, reports are ok (commendable coverage btw, nit JIRA report with no version and Tag List report shows a lot of todo/fixme/etc). Built using: mvn -P jacoco -P japicmp clean install site -s ~/.m2/commons-settings.xml With JDK: openjdk version "21.0.3" 2024-04-16 LTS OpenJDK Runtime Environment Zulu21.34+19-CA (build 21.0.3+9-LTS) OpenJDK 64-Bit Server VM Zulu21.34+19-CA (build 21.0.3+9-LTS, mixed mode, sharing) And maven: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 Java version: 21.0.3, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac" - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC2
+1 all looks good. Signatures, site release notes, builds java 11, 17, 21. Thank you Gary!!! -Rob > On Jul 13, 2024, at 7:08 PM, Gary Gregory wrote: > > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.14.0 was released, so I would like to release Apache Commons > Lang 3.15.0. > > Apache Commons Lang 3.15.0 RC2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2 > (svn revision 70292) > > The Git tag commons-lang-3.15.0-RC2 commit for this RC is > 535ec32c680a6581739a41bf97ecb8b8718c73b8 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=535ec32c680a6581739a41bf97ecb8b8718c73b8 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch commons-lang-3.15.0-RC2 commons-lang-3.15.0-RC2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1760/org/apache/commons/commons-lang3/3.15.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Jul 13 22:56:40 UTC 2024 > commons-lang3-3.15.0-bin.tar.gz=b202d6d43785ad4813f3379b94603ee50d0ed7fa702d5e413a97e0fe7b24d679448e44547c4408ac1c7831da0baa1396ce91ba8f0a02764e33d4387c2350bcdf > commons-lang3-3.15.0-bin.zip=8bee18ea4f4c0e87ac83806c805af91786055a96ccc6a9f760323f5abe851355fc7b14637246e3f5f5612c8774d6b0579426d325b21cffe98b623c35703e0434 > commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca > commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea > commons-lang3-3.15.0-javadoc.jar=bc351ba2b94a951f96df59f0b029ea0060e97f8e0896a22308ee51d21a67b4258ef64736597c8660eab2f9df6d21ef3b9f1f10f4c10156a757e449c2bce78219 > commons-lang3-3.15.0-sources.jar=0f567c6eebc73e9dfa98e7cbeda5ef275ef026d1bfbf1d02d96d65594d058bc07961742f270b888f64023b756a20db1e4aa8b29ea7acd6ab079b3d3257f3ad27 > commons-lang3-3.15.0-src.tar.gz=530fa9200d8a004b2bb917e095486d7eebea93b84cdbdaaf8fb952e1c160043306daadc168d67ffdcb277b4b00d3b9db876257a08a5dce5713dcd3abd5ec802b > commons-lang3-3.15.0-src.zip=a28c41293b0be816db246f8353c12b8636a5ad62a6913446a5462ee2e66d3471beec2dd53f30ab8f6576dc383d5828279ff0c2b32872806ae46633c7a639358e > commons-lang3-3.15.0-test-sources.jar=b3017447cf41a86677a917493b5ff0cb2530ebd8cde2591b6e9ecd23374e6731dc3cfb3c57898bf5cb9a242fc09e2d54aa68595e22d664b0551ea4c9ef76f1f7 > commons-lang3-3.15.0-tests.jar=7baa621a90c1e3f8264f2a8a5e8f24ad5fa6dc5f81a549a2581dcfb2cf6a8be92f88679aa650c2a48ded8da6cca18caab8a25e7ae9703a8f27ba626c68dd3348 > org.apache.commons_commons-lang3-3.15.0.spdx.json=7511388b70b282639dbdeee9afed69e65e2858e8741170dfd85bc56dbe8d748aab1a3fd880669f03b8ee26c4e710fdce1e673ae8049ecf3e0b984f4b6f8e > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy ' using: > > openjdk version "17.0.11" 2024-04-16 > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 17.0.11, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.14.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/index.html >(note some *relative* links are broken and the 3.15.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.14.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC2
Tomas, What did you do to review the release candidate? TY, Gary On 2024/07/15 06:47:37 Tomas Lanik wrote: > My +1 > > Tomas Lanik > > On Sun, Jul 14, 2024, 01:09 Gary Gregory wrote: > > > We have fixed a few bugs and added enhancements since Apache Commons > > Lang 3.14.0 was released, so I would like to release Apache Commons > > Lang 3.15.0. > > > > Apache Commons Lang 3.15.0 RC2 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2 > > (svn revision 70292) > > > > The Git tag commons-lang-3.15.0-RC2 commit for this RC is > > 535ec32c680a6581739a41bf97ecb8b8718c73b8 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=535ec32c680a6581739a41bf97ecb8b8718c73b8 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > > --branch <https://gitbox.apache.org/repos/asf/commons-lang.git--branch> > > commons-lang-3.15.0-RC2 commons-lang-3.15.0-RC2 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1760/org/apache/commons/commons-lang3/3.15.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Sat Jul 13 22:56:40 UTC 2024 > > > > commons-lang3-3.15.0-bin.tar.gz=b202d6d43785ad4813f3379b94603ee50d0ed7fa702d5e413a97e0fe7b24d679448e44547c4408ac1c7831da0baa1396ce91ba8f0a02764e33d4387c2350bcdf > > > > commons-lang3-3.15.0-bin.zip=8bee18ea4f4c0e87ac83806c805af91786055a96ccc6a9f760323f5abe851355fc7b14637246e3f5f5612c8774d6b0579426d325b21cffe98b623c35703e0434 > > > > commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca > > > > commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea > > > > commons-lang3-3.15.0-javadoc.jar=bc351ba2b94a951f96df59f0b029ea0060e97f8e0896a22308ee51d21a67b4258ef64736597c8660eab2f9df6d21ef3b9f1f10f4c10156a757e449c2bce78219 > > > > commons-lang3-3.15.0-sources.jar=0f567c6eebc73e9dfa98e7cbeda5ef275ef026d1bfbf1d02d96d65594d058bc07961742f270b888f64023b756a20db1e4aa8b29ea7acd6ab079b3d3257f3ad27 > > > > commons-lang3-3.15.0-src.tar.gz=530fa9200d8a004b2bb917e095486d7eebea93b84cdbdaaf8fb952e1c160043306daadc168d67ffdcb277b4b00d3b9db876257a08a5dce5713dcd3abd5ec802b > > > > commons-lang3-3.15.0-src.zip=a28c41293b0be816db246f8353c12b8636a5ad62a6913446a5462ee2e66d3471beec2dd53f30ab8f6576dc383d5828279ff0c2b32872806ae46633c7a639358e > > > > commons-lang3-3.15.0-test-sources.jar=b3017447cf41a86677a917493b5ff0cb2530ebd8cde2591b6e9ecd23374e6731dc3cfb3c57898bf5cb9a242fc09e2d54aa68595e22d664b0551ea4c9ef76f1f7 > > > > commons-lang3-3.15.0-tests.jar=7baa621a90c1e3f8264f2a8a5e8f24ad5fa6dc5f81a549a2581dcfb2cf6a8be92f88679aa650c2a48ded8da6cca18caab8a25e7ae9703a8f27ba626c68dd3348 > > > > org.apache.commons_commons-lang3-3.15.0.spdx.json=7511388b70b282639dbdeee9afed69e65e2858e8741170dfd85bc56dbe8d748aab1a3fd880669f03b8ee26c4e710fdce1e673ae8049ecf3e0b984f4b6f8e > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > > -P jacoco -P japicmp clean package site deploy ' using: > > > > openjdk version "17.0.11" 2024-04-16 > > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > > Java version: 17.0.11, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.14.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/index.html > > (note some *relative* links are broken and the 3.15.0 directories > > are not yet created - these will be O
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC2
My +1 Tomas Lanik On Sun, Jul 14, 2024, 01:09 Gary Gregory wrote: > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.14.0 was released, so I would like to release Apache Commons > Lang 3.15.0. > > Apache Commons Lang 3.15.0 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2 > (svn revision 70292) > > The Git tag commons-lang-3.15.0-RC2 commit for this RC is > 535ec32c680a6581739a41bf97ecb8b8718c73b8 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=535ec32c680a6581739a41bf97ecb8b8718c73b8 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch <https://gitbox.apache.org/repos/asf/commons-lang.git--branch> > commons-lang-3.15.0-RC2 commons-lang-3.15.0-RC2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1760/org/apache/commons/commons-lang3/3.15.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Jul 13 22:56:40 UTC 2024 > > commons-lang3-3.15.0-bin.tar.gz=b202d6d43785ad4813f3379b94603ee50d0ed7fa702d5e413a97e0fe7b24d679448e44547c4408ac1c7831da0baa1396ce91ba8f0a02764e33d4387c2350bcdf > > commons-lang3-3.15.0-bin.zip=8bee18ea4f4c0e87ac83806c805af91786055a96ccc6a9f760323f5abe851355fc7b14637246e3f5f5612c8774d6b0579426d325b21cffe98b623c35703e0434 > > commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca > > commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea > > commons-lang3-3.15.0-javadoc.jar=bc351ba2b94a951f96df59f0b029ea0060e97f8e0896a22308ee51d21a67b4258ef64736597c8660eab2f9df6d21ef3b9f1f10f4c10156a757e449c2bce78219 > > commons-lang3-3.15.0-sources.jar=0f567c6eebc73e9dfa98e7cbeda5ef275ef026d1bfbf1d02d96d65594d058bc07961742f270b888f64023b756a20db1e4aa8b29ea7acd6ab079b3d3257f3ad27 > > commons-lang3-3.15.0-src.tar.gz=530fa9200d8a004b2bb917e095486d7eebea93b84cdbdaaf8fb952e1c160043306daadc168d67ffdcb277b4b00d3b9db876257a08a5dce5713dcd3abd5ec802b > > commons-lang3-3.15.0-src.zip=a28c41293b0be816db246f8353c12b8636a5ad62a6913446a5462ee2e66d3471beec2dd53f30ab8f6576dc383d5828279ff0c2b32872806ae46633c7a639358e > > commons-lang3-3.15.0-test-sources.jar=b3017447cf41a86677a917493b5ff0cb2530ebd8cde2591b6e9ecd23374e6731dc3cfb3c57898bf5cb9a242fc09e2d54aa68595e22d664b0551ea4c9ef76f1f7 > > commons-lang3-3.15.0-tests.jar=7baa621a90c1e3f8264f2a8a5e8f24ad5fa6dc5f81a549a2581dcfb2cf6a8be92f88679aa650c2a48ded8da6cca18caab8a25e7ae9703a8f27ba626c68dd3348 > > org.apache.commons_commons-lang3-3.15.0.spdx.json=7511388b70b282639dbdeee9afed69e65e2858e8741170dfd85bc56dbe8d748aab1a3fd880669f03b8ee26c4e710fdce1e673ae8049ecf3e0b984f4b6f8e > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy ' using: > > openjdk version "17.0.11" 2024-04-16 > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 17.0.11, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.14.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/index.html > (note some *relative* links are broken and the 3.15.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.14.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ]
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC2
My +1 Gary On Sat, Jul 13, 2024, 7:08 PM Gary Gregory wrote: > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.14.0 was released, so I would like to release Apache Commons > Lang 3.15.0. > > Apache Commons Lang 3.15.0 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2 > (svn revision 70292) > > The Git tag commons-lang-3.15.0-RC2 commit for this RC is > 535ec32c680a6581739a41bf97ecb8b8718c73b8 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=535ec32c680a6581739a41bf97ecb8b8718c73b8 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch <https://gitbox.apache.org/repos/asf/commons-lang.git--branch> > commons-lang-3.15.0-RC2 commons-lang-3.15.0-RC2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1760/org/apache/commons/commons-lang3/3.15.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Jul 13 22:56:40 UTC 2024 > > commons-lang3-3.15.0-bin.tar.gz=b202d6d43785ad4813f3379b94603ee50d0ed7fa702d5e413a97e0fe7b24d679448e44547c4408ac1c7831da0baa1396ce91ba8f0a02764e33d4387c2350bcdf > > commons-lang3-3.15.0-bin.zip=8bee18ea4f4c0e87ac83806c805af91786055a96ccc6a9f760323f5abe851355fc7b14637246e3f5f5612c8774d6b0579426d325b21cffe98b623c35703e0434 > > commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca > > commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea > > commons-lang3-3.15.0-javadoc.jar=bc351ba2b94a951f96df59f0b029ea0060e97f8e0896a22308ee51d21a67b4258ef64736597c8660eab2f9df6d21ef3b9f1f10f4c10156a757e449c2bce78219 > > commons-lang3-3.15.0-sources.jar=0f567c6eebc73e9dfa98e7cbeda5ef275ef026d1bfbf1d02d96d65594d058bc07961742f270b888f64023b756a20db1e4aa8b29ea7acd6ab079b3d3257f3ad27 > > commons-lang3-3.15.0-src.tar.gz=530fa9200d8a004b2bb917e095486d7eebea93b84cdbdaaf8fb952e1c160043306daadc168d67ffdcb277b4b00d3b9db876257a08a5dce5713dcd3abd5ec802b > > commons-lang3-3.15.0-src.zip=a28c41293b0be816db246f8353c12b8636a5ad62a6913446a5462ee2e66d3471beec2dd53f30ab8f6576dc383d5828279ff0c2b32872806ae46633c7a639358e > > commons-lang3-3.15.0-test-sources.jar=b3017447cf41a86677a917493b5ff0cb2530ebd8cde2591b6e9ecd23374e6731dc3cfb3c57898bf5cb9a242fc09e2d54aa68595e22d664b0551ea4c9ef76f1f7 > > commons-lang3-3.15.0-tests.jar=7baa621a90c1e3f8264f2a8a5e8f24ad5fa6dc5f81a549a2581dcfb2cf6a8be92f88679aa650c2a48ded8da6cca18caab8a25e7ae9703a8f27ba626c68dd3348 > > org.apache.commons_commons-lang3-3.15.0.spdx.json=7511388b70b282639dbdeee9afed69e65e2858e8741170dfd85bc56dbe8d748aab1a3fd880669f03b8ee26c4e710fdce1e673ae8049ecf3e0b984f4b6f8e > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy ' using: > > openjdk version "17.0.11" 2024-04-16 > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 17.0.11, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 3.14.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/index.html > (note some *relative* links are broken and the 3.15.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.14.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ]
RE: [CANCEL][VOTE] Release Apache Commons Lang 3.15.0 based on RC1
On 2024/07/13 22:41:16 Gary Gregory wrote: > This RC is canceled. RC2 on the way. > > Gary > > > On Sat, Jul 13, 2024 at 6:40 PM Gary Gregory wrote: > > > > Good catch! I'll spin another RC. > > > > Gary > > > > > > Gary > > > > On Sat, Jul 13, 2024 at 5:04 PM Gilles Sadowski wrote: > > > > > > Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit : > > > > > > > > We have fixed a few bugs and added enhancements since Apache Commons > > > > Lang 3.14.0 was released, so I would like to release Apache Commons > > > > Lang 3.15.0. > > > > > > > > > > What about point (2) in > > > https://lists.apache.org/thread/d48y7grxs4qoy49r1qk9rg8ym0y6h1o5 > > > ? > > > > > > > [...] > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[VOTE] Release Apache Commons Lang 3.15.0 based on RC2
We have fixed a few bugs and added enhancements since Apache Commons Lang 3.14.0 was released, so I would like to release Apache Commons Lang 3.15.0. Apache Commons Lang 3.15.0 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2 (svn revision 70292) The Git tag commons-lang-3.15.0-RC2 commit for this RC is 535ec32c680a6581739a41bf97ecb8b8718c73b8 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=535ec32c680a6581739a41bf97ecb8b8718c73b8 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-lang-3.15.0-RC2 commons-lang-3.15.0-RC2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1760/org/apache/commons/commons-lang3/3.15.0/ These are the artifacts and their hashes: #Release SHA-512s #Sat Jul 13 22:56:40 UTC 2024 commons-lang3-3.15.0-bin.tar.gz=b202d6d43785ad4813f3379b94603ee50d0ed7fa702d5e413a97e0fe7b24d679448e44547c4408ac1c7831da0baa1396ce91ba8f0a02764e33d4387c2350bcdf commons-lang3-3.15.0-bin.zip=8bee18ea4f4c0e87ac83806c805af91786055a96ccc6a9f760323f5abe851355fc7b14637246e3f5f5612c8774d6b0579426d325b21cffe98b623c35703e0434 commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea commons-lang3-3.15.0-javadoc.jar=bc351ba2b94a951f96df59f0b029ea0060e97f8e0896a22308ee51d21a67b4258ef64736597c8660eab2f9df6d21ef3b9f1f10f4c10156a757e449c2bce78219 commons-lang3-3.15.0-sources.jar=0f567c6eebc73e9dfa98e7cbeda5ef275ef026d1bfbf1d02d96d65594d058bc07961742f270b888f64023b756a20db1e4aa8b29ea7acd6ab079b3d3257f3ad27 commons-lang3-3.15.0-src.tar.gz=530fa9200d8a004b2bb917e095486d7eebea93b84cdbdaaf8fb952e1c160043306daadc168d67ffdcb277b4b00d3b9db876257a08a5dce5713dcd3abd5ec802b commons-lang3-3.15.0-src.zip=a28c41293b0be816db246f8353c12b8636a5ad62a6913446a5462ee2e66d3471beec2dd53f30ab8f6576dc383d5828279ff0c2b32872806ae46633c7a639358e commons-lang3-3.15.0-test-sources.jar=b3017447cf41a86677a917493b5ff0cb2530ebd8cde2591b6e9ecd23374e6731dc3cfb3c57898bf5cb9a242fc09e2d54aa68595e22d664b0551ea4c9ef76f1f7 commons-lang3-3.15.0-tests.jar=7baa621a90c1e3f8264f2a8a5e8f24ad5fa6dc5f81a549a2581dcfb2cf6a8be92f88679aa650c2a48ded8da6cca18caab8a25e7ae9703a8f27ba626c68dd3348 org.apache.commons_commons-lang3-3.15.0.spdx.json=7511388b70b282639dbdeee9afed69e65e2858e8741170dfd85bc56dbe8d748aab1a3fd880669f03b8ee26c4e710fdce1e673ae8049ecf3e0b984f4b6f8e I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy ' using: openjdk version "17.0.11" 2024-04-16 OpenJDK Runtime Environment Homebrew (build 17.0.11+0) OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /usr/local/Cellar/maven/3.9.8/libexec Java version: 17.0.11, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 Details of changes since 3.14.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/index.html (note some *relative* links are broken and the 3.15.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.14.0): https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) The following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-
[CANCEL][VOTE] Release Apache Commons Lang 3.15.0 based on RC1
This RC is canceled. RC2 on the way. Gary On Sat, Jul 13, 2024 at 6:40 PM Gary Gregory wrote: > > Good catch! I'll spin another RC. > > Gary > > > Gary > > On Sat, Jul 13, 2024 at 5:04 PM Gilles Sadowski wrote: > > > > Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit : > > > > > > We have fixed a few bugs and added enhancements since Apache Commons > > > Lang 3.14.0 was released, so I would like to release Apache Commons > > > Lang 3.15.0. > > > > > > > What about point (2) in > > https://lists.apache.org/thread/d48y7grxs4qoy49r1qk9rg8ym0y6h1o5 > > ? > > > > > [...] > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC1
Good catch! I'll spin another RC. Gary Gary On Sat, Jul 13, 2024 at 5:04 PM Gilles Sadowski wrote: > > Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit : > > > > We have fixed a few bugs and added enhancements since Apache Commons > > Lang 3.14.0 was released, so I would like to release Apache Commons > > Lang 3.15.0. > > > > What about point (2) in > https://lists.apache.org/thread/d48y7grxs4qoy49r1qk9rg8ym0y6h1o5 > ? > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.15.0 based on RC1
Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit : > > We have fixed a few bugs and added enhancements since Apache Commons > Lang 3.14.0 was released, so I would like to release Apache Commons > Lang 3.15.0. > What about point (2) in https://lists.apache.org/thread/d48y7grxs4qoy49r1qk9rg8ym0y6h1o5 ? > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Apache Commons Lang 3.15.0 based on RC1
We have fixed a few bugs and added enhancements since Apache Commons Lang 3.14.0 was released, so I would like to release Apache Commons Lang 3.15.0. Apache Commons Lang 3.15.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1 (svn revision 70284) The Git tag commons-lang-3.15.0-RC1 commit for this RC is a0bf7894ca8b8cf312c068c5c1618d24fd064acf which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=a0bf7894ca8b8cf312c068c5c1618d24fd064acf You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-lang-3.15.0-RC1 commons-lang-3.15.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1758/org/apache/commons/commons-lang3/3.15.0/ These are the artifacts and their hashes: #Release SHA-512s #Sat Jul 13 15:03:28 UTC 2024 commons-lang3-3.15.0-bin.tar.gz=64ac08ddb74f1fa2f564bdb03ced5f92eeed0a984a3281593e8eb8939bc112e7444cf3d45e5e2a36a77e8981e23b57cacc48f6fa121f08b0e949545787a0f503 commons-lang3-3.15.0-bin.zip=bac4816190bd14395c10fbd431839e88fc1ffdda74c6de763af6f04f62829a555b5a63490db7212c288ddcb2f4bb9306d5e0d158890cec656b011c67042848e0 commons-lang3-3.15.0-bom.json=7473cb182e0ea855b54459c572cce0673ff780f3703aa3f629bf1d42acc921924792b7bfcd6073df89f5787c503df8def5c0b0581f83560ccc1faf81eff6b3ca commons-lang3-3.15.0-bom.xml=cecaf68e2e6ebd9345273defd46bd6f0b31323e2e31ec7e9cb9e439ca26a55db26dfe18e82208f9f398a3256d9f9104d4d3f4fa2bf6f54556c112b6d5f44a6ea commons-lang3-3.15.0-javadoc.jar=6ae9e90a4c9313307b5f515349a11b83f3f59c6483d8dc0d5ef9bd2c40985a878ebb5f8b9f170ed9c40739309531e72b07b302a7d89d9c740a0845449a4b34be commons-lang3-3.15.0-sources.jar=e9eb653025a35785f35dc3362e2a1e1117388ab62bb3fd47820c003fd97d9bbee1d7b9ec165dccdc76bc034a7619b0f88ddc86aaeff11888c991f59d552b93f6 commons-lang3-3.15.0-src.tar.gz=9e618284330b579b2412420e123b46b02eeba0f47e2b3a35f0d215c6bdcb5f8b2bac29104dd577632d74b4799d8f99b8c8c8bdc7426316a38a379102478112b5 commons-lang3-3.15.0-src.zip=f08d669613fc8b34e382f98ffb4ad1d7bfc390ed16aba743f5db5c2f2f56529ad13a28663e11075a543eea47be994cc41e7510ba174305f230888537fcae3ade commons-lang3-3.15.0-test-sources.jar=361086cc9aa8bed92244123f29a8573cc6ac82d0f2e2b99e87516f4cb354cffb515d52467100f39e766467600c6118489113df5f37451d97def408d24e1d94aa commons-lang3-3.15.0-tests.jar=0faa61bea772f7b9dda7679004fa2c65de15d3dbbe67073b78e011ab7c4796c80b62057988efa7dca45e0cee881432cbc2a2037eddc09ed1d838995ad111c882 org.apache.commons_commons-lang3-3.15.0.spdx.json=dbadf3540746700c143b0b1dcea1f66b17374cbdd2741e8695b347127dba6dbe38bf24eaa52ad25e911eb2cbd006569ba9375d5f01fc57efdfc39f47b40fea15 I have tested this with 'mvn 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: openjdk version "17.0.11" 2024-04-16 OpenJDK Runtime Environment Homebrew (build 17.0.11+0) OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /usr/local/Cellar/maven/3.9.8/libexec Java version: 17.0.11, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 Details of changes since 3.14.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1/site/index.html (note some *relative* links are broken and the 3.15.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.14.0): https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) The following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch commons-lang-
Re: [apache/commons-lang] Reimplement RandomStringUtils on top of SecureRandom#getInstanceStrong() (PR #1235)
On Fri, Jun 14, 2024 at 4:13 PM Fabrice Benhamouda wrote: > Thanks @psteitz <https://github.com/psteitz> ! I am not sure where is the > best place to post the following comment. If you think it’s more > appropriate to post it to the mailing list, let me know and I will post it > there. > > To address the point "1) gen time performance cost", I’ve written some > optimizations on top of the current PR: garydgregory#2 > <https://github.com/garydgregory/commons-lang/pull/2> > > Benchmarking using JMH with JDK 8 on an AWS c6a.xlarge instance with > cryptographic providers SUN/NativePRNG, SUN/SHA1PRNG, ACCP > <https://github.com/corretto/amazon-corretto-crypto-provider> 1.6, and > ACCP <https://github.com/corretto/amazon-corretto-crypto-provider> 2.3, > we have the following results. Compared to the current state (with the > default java.util.Random/ThreadLocalRandom number generator), when any of > the above SecureRandom is used with the optimized code, the time to > generate random alphabetic, alphanumeric, and numeric strings of at least > 16 characters is less than three times slower (and sometimes even 5x > faster). For 4-character strings, we observe a slow-down of at most 8x. > > If the optimized RandomStringUtils is called concurrently in multiple > threads, the SUN/NativePrng SecureRandom implementation (the default on > Linux) may be slower as calls are serialized (due to access to/dev/random. > This is the use case I would be most concerned with. Many web applications use this class in multi-threaded app server settings. I would not use the class in web apps after this change for that reason. If we do make the change, we should make it clear in the class javadoc that it is using SecureRandom and prone to occasional stalls. Since there was no discussion about why this change is being made, I will ask again why it is being proposed. The only rationale that I can see is that somehow some users are using the class to generate things that should be cryptographically secure, like passwords or hash salt, so to protect these users, we make all other users take a potential performance hit. Much better, IMO, would be to make the recommended improvements in performance to the vanilla Random-based impl and add a new class or somehow shoehorn in a secure impl for users that want / need that. Phil This seems an unlikely scenario in practice. In addition, switching to ACCP 2 for SecureRandom would fix the performance issue in that case. > — > Reply to this email directly, view it on GitHub > <https://github.com/apache/commons-lang/pull/1235#issuecomment-2168869983>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AALJJ2W2FHEF7BLURVCM3HDZHN2LFAVCNFSM6ABJJE3MF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYHA3DSOJYGM> > . > You are receiving this because you were mentioned.Message ID: > >
Re: [LANG] Add Any Checks for Not Checks in StringUtils
No problem this was actually my first time engaging in any Open source
contribution, so it was a good way to know what should be done in quality
and quantity for any open source contribution, so thanks for helping me
learn as well.
On Thu, Jun 13, 2024, 19:13 Gary D. Gregory wrote:
> On 2024/06/13 00:22:13 Department 8 wrote:
> > I see the point you are making. Thanks for taking the time to review it.
>
> And thank you for engaging with us on improving this component! :-)
>
> Gary
>
> >
> > On Wed, Jun 12, 2024, 23:30 Gary Gregory wrote:
> >
> > > See also my comment in the PR.
> > >
> > > Gary
> > >
> > > On Wed, Jun 12, 2024, 1:22 PM Department 8
> > > wrote:
> > >
> > > > Haha! It was in fact because of other methods that have simple
> negation
> > > > that I thought maybe giving a PR would be Okay :)
> > > >
> > > > I think that many times, it is the Boolean Logic that may trivial
> for us,
> > > > but for some who may be using them to have a utility methods like
> > > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the
> client
> > > > code to a good extent. So it is more of a clean fix for them.
> > > >
> > > > Another way may be to - do a for loop on all of them and once you
> find
> > > > NotBlank to be true you return true, else iterate till end and return
> > > false
> > > > (the actual negated logic of isAllBlank) but that would mean for the
> > > > clients of the API to write that helper function for themselves. So
> this
> > > > can provide an easy wrap.
> > > >
> > > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert >
> > > > wrote:
> > > >
> > > > > On Wed, 12 Jun 2024 at 18:03, Department 8 <
> manstein.fe...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > > >
> > > > > > I had done just for isAllEmpty and isAllBlank.
> > > > > >
> > > > > > Can you tell me more on what can be done, when you said the
> > > following:
> > > > > >
> > > > > > If you are simply negating the result of another method then
> this use
> > > > > case
> > > > > > may be better served with addition of a suitable example to the
> > > javadoc
> > > > > of
> > > > > > the method you are negating.
> > > > > >
> > > > > > Like do you want me to add examples of use-cases?
> > > > > >
> > > > >
> > > > > I've seen the PR. The new methods are a simple boolean negation of
> > > > existing
> > > > > methods. So these are not adding functionality that cannot be
> achieved
> > > > with
> > > > > the current API.
> > > > >
> > > > > Note that a quick check in StringUtils for 'return !' finds these
> > > > methods:
> > > > >
> > > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > > > return !isAnyBlank(css);
> > > > > }
> > > > >
> > > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > > return !isAnyEmpty(css);
> > > > > }
> > > > >
> > > > > There are two others for single CharSequence args as well:
> isNotBlank
> > > and
> > > > > isNotEmpty.
> > > > >
> > > > > So it is not without precedent to add more methods that are simple
> > > > > negations. However we have to consider if this is code bloat, or
> if the
> > > > > addition of simple negation methods is so useful that it warrants
> > > > > inclusion. I would currently consider this as redundant given the
> lack
> > > of
> > > > > actual logic in the methods.
> > > > >
> > > > > Alex
> > > > >
> > > > >
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 22:29, Department 8 <
> manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I just realized the subject name is bad. But here are the two
> small
> > > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > > >
> > > > > > > Please find the pull request as here:
> > > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > > >
> > > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > > manstein.fe...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hey!
> > > > > > >>
> > > > > > >> Recently when using StringUtils in one of our projects I had
> felt
> > > > the
> > > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > > >>
> > > > > > >> I was able to achieve this using the negation of isAllBlank,
> so I
> > > am
> > > > > > >> thinking of introducing the code with all tests.
> > > > > > >>
> > > > > > >> It is ready to be pushed to PR. Do let me know what you think
> and
> > > > what
> > > > > > >> are the next steps for the same?
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
On 2024/06/13 00:22:13 Department 8 wrote:
> I see the point you are making. Thanks for taking the time to review it.
And thank you for engaging with us on improving this component! :-)
Gary
>
> On Wed, Jun 12, 2024, 23:30 Gary Gregory wrote:
>
> > See also my comment in the PR.
> >
> > Gary
> >
> > On Wed, Jun 12, 2024, 1:22 PM Department 8
> > wrote:
> >
> > > Haha! It was in fact because of other methods that have simple negation
> > > that I thought maybe giving a PR would be Okay :)
> > >
> > > I think that many times, it is the Boolean Logic that may trivial for us,
> > > but for some who may be using them to have a utility methods like
> > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> > > code to a good extent. So it is more of a clean fix for them.
> > >
> > > Another way may be to - do a for loop on all of them and once you find
> > > NotBlank to be true you return true, else iterate till end and return
> > false
> > > (the actual negated logic of isAllBlank) but that would mean for the
> > > clients of the API to write that helper function for themselves. So this
> > > can provide an easy wrap.
> > >
> > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert
> > > wrote:
> > >
> > > > On Wed, 12 Jun 2024 at 18:03, Department 8
> > > > wrote:
> > > >
> > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > >
> > > > > I had done just for isAllEmpty and isAllBlank.
> > > > >
> > > > > Can you tell me more on what can be done, when you said the
> > following:
> > > > >
> > > > > If you are simply negating the result of another method then this use
> > > > case
> > > > > may be better served with addition of a suitable example to the
> > javadoc
> > > > of
> > > > > the method you are negating.
> > > > >
> > > > > Like do you want me to add examples of use-cases?
> > > > >
> > > >
> > > > I've seen the PR. The new methods are a simple boolean negation of
> > > existing
> > > > methods. So these are not adding functionality that cannot be achieved
> > > with
> > > > the current API.
> > > >
> > > > Note that a quick check in StringUtils for 'return !' finds these
> > > methods:
> > > >
> > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > > return !isAnyBlank(css);
> > > > }
> > > >
> > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > return !isAnyEmpty(css);
> > > > }
> > > >
> > > > There are two others for single CharSequence args as well: isNotBlank
> > and
> > > > isNotEmpty.
> > > >
> > > > So it is not without precedent to add more methods that are simple
> > > > negations. However we have to consider if this is code bloat, or if the
> > > > addition of simple negation methods is so useful that it warrants
> > > > inclusion. I would currently consider this as redundant given the lack
> > of
> > > > actual logic in the methods.
> > > >
> > > > Alex
> > > >
> > > >
> > > > >
> > > > > On Wed, 12 Jun 2024 at 22:29, Department 8 > >
> > > > > wrote:
> > > > >
> > > > > > I just realized the subject name is bad. But here are the two small
> > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > >
> > > > > > Please find the pull request as here:
> > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hey!
> > > > > >>
> > > > > >> Recently when using StringUtils in one of our projects I had felt
> > > the
> > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > >>
> > > > > >> I was able to achieve this using the negation of isAllBlank, so I
> > am
> > > > > >> thinking of introducing the code with all tests.
> > > > > >>
> > > > > >> It is ready to be pushed to PR. Do let me know what you think and
> > > what
> > > > > >> are the next steps for the same?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Add Any Checks for Not Checks in StringUtils
I see the point you are making. Thanks for taking the time to review it.
On Wed, Jun 12, 2024, 23:30 Gary Gregory wrote:
> See also my comment in the PR.
>
> Gary
>
> On Wed, Jun 12, 2024, 1:22 PM Department 8
> wrote:
>
> > Haha! It was in fact because of other methods that have simple negation
> > that I thought maybe giving a PR would be Okay :)
> >
> > I think that many times, it is the Boolean Logic that may trivial for us,
> > but for some who may be using them to have a utility methods like
> > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> > code to a good extent. So it is more of a clean fix for them.
> >
> > Another way may be to - do a for loop on all of them and once you find
> > NotBlank to be true you return true, else iterate till end and return
> false
> > (the actual negated logic of isAllBlank) but that would mean for the
> > clients of the API to write that helper function for themselves. So this
> > can provide an easy wrap.
> >
> > On Wed, 12 Jun 2024 at 22:43, Alex Herbert
> > wrote:
> >
> > > On Wed, 12 Jun 2024 at 18:03, Department 8
> > > wrote:
> > >
> > > > Sorry Alex just now saw your email, before sending out the PR!
> > > >
> > > > I had done just for isAllEmpty and isAllBlank.
> > > >
> > > > Can you tell me more on what can be done, when you said the
> following:
> > > >
> > > > If you are simply negating the result of another method then this use
> > > case
> > > > may be better served with addition of a suitable example to the
> javadoc
> > > of
> > > > the method you are negating.
> > > >
> > > > Like do you want me to add examples of use-cases?
> > > >
> > >
> > > I've seen the PR. The new methods are a simple boolean negation of
> > existing
> > > methods. So these are not adding functionality that cannot be achieved
> > with
> > > the current API.
> > >
> > > Note that a quick check in StringUtils for 'return !' finds these
> > methods:
> > >
> > > public static boolean isNoneBlank(final CharSequence... css) {
> > > return !isAnyBlank(css);
> > > }
> > >
> > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > return !isAnyEmpty(css);
> > > }
> > >
> > > There are two others for single CharSequence args as well: isNotBlank
> and
> > > isNotEmpty.
> > >
> > > So it is not without precedent to add more methods that are simple
> > > negations. However we have to consider if this is code bloat, or if the
> > > addition of simple negation methods is so useful that it warrants
> > > inclusion. I would currently consider this as redundant given the lack
> of
> > > actual logic in the methods.
> > >
> > > Alex
> > >
> > >
> > > >
> > > > On Wed, 12 Jun 2024 at 22:29, Department 8 >
> > > > wrote:
> > > >
> > > > > I just realized the subject name is bad. But here are the two small
> > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > >
> > > > > Please find the pull request as here:
> > > > > https://github.com/apache/commons-lang/pull/1234
> > > > >
> > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> manstein.fe...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > >> Hey!
> > > > >>
> > > > >> Recently when using StringUtils in one of our projects I had felt
> > the
> > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > >>
> > > > >> I was able to achieve this using the negation of isAllBlank, so I
> am
> > > > >> thinking of introducing the code with all tests.
> > > > >>
> > > > >> It is ready to be pushed to PR. Do let me know what you think and
> > what
> > > > >> are the next steps for the same?
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
See also my comment in the PR.
Gary
On Wed, Jun 12, 2024, 1:22 PM Department 8 wrote:
> Haha! It was in fact because of other methods that have simple negation
> that I thought maybe giving a PR would be Okay :)
>
> I think that many times, it is the Boolean Logic that may trivial for us,
> but for some who may be using them to have a utility methods like
> isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> code to a good extent. So it is more of a clean fix for them.
>
> Another way may be to - do a for loop on all of them and once you find
> NotBlank to be true you return true, else iterate till end and return false
> (the actual negated logic of isAllBlank) but that would mean for the
> clients of the API to write that helper function for themselves. So this
> can provide an easy wrap.
>
> On Wed, 12 Jun 2024 at 22:43, Alex Herbert
> wrote:
>
> > On Wed, 12 Jun 2024 at 18:03, Department 8
> > wrote:
> >
> > > Sorry Alex just now saw your email, before sending out the PR!
> > >
> > > I had done just for isAllEmpty and isAllBlank.
> > >
> > > Can you tell me more on what can be done, when you said the following:
> > >
> > > If you are simply negating the result of another method then this use
> > case
> > > may be better served with addition of a suitable example to the javadoc
> > of
> > > the method you are negating.
> > >
> > > Like do you want me to add examples of use-cases?
> > >
> >
> > I've seen the PR. The new methods are a simple boolean negation of
> existing
> > methods. So these are not adding functionality that cannot be achieved
> with
> > the current API.
> >
> > Note that a quick check in StringUtils for 'return !' finds these
> methods:
> >
> > public static boolean isNoneBlank(final CharSequence... css) {
> > return !isAnyBlank(css);
> > }
> >
> > public static boolean isNoneEmpty(final CharSequence... css) {
> > return !isAnyEmpty(css);
> > }
> >
> > There are two others for single CharSequence args as well: isNotBlank and
> > isNotEmpty.
> >
> > So it is not without precedent to add more methods that are simple
> > negations. However we have to consider if this is code bloat, or if the
> > addition of simple negation methods is so useful that it warrants
> > inclusion. I would currently consider this as redundant given the lack of
> > actual logic in the methods.
> >
> > Alex
> >
> >
> > >
> > > On Wed, 12 Jun 2024 at 22:29, Department 8
> > > wrote:
> > >
> > > > I just realized the subject name is bad. But here are the two small
> > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > >
> > > > Please find the pull request as here:
> > > > https://github.com/apache/commons-lang/pull/1234
> > > >
> > > > On Wed, 12 Jun 2024 at 21:52, Department 8 >
> > > > wrote:
> > > >
> > > >> Hey!
> > > >>
> > > >> Recently when using StringUtils in one of our projects I had felt
> the
> > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > >>
> > > >> I was able to achieve this using the negation of isAllBlank, so I am
> > > >> thinking of introducing the code with all tests.
> > > >>
> > > >> It is ready to be pushed to PR. Do let me know what you think and
> what
> > > >> are the next steps for the same?
> > > >>
> > > >>
> > > >>
> > >
> >
>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
Haha! It was in fact because of other methods that have simple negation
that I thought maybe giving a PR would be Okay :)
I think that many times, it is the Boolean Logic that may trivial for us,
but for some who may be using them to have a utility methods like
isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
code to a good extent. So it is more of a clean fix for them.
Another way may be to - do a for loop on all of them and once you find
NotBlank to be true you return true, else iterate till end and return false
(the actual negated logic of isAllBlank) but that would mean for the
clients of the API to write that helper function for themselves. So this
can provide an easy wrap.
On Wed, 12 Jun 2024 at 22:43, Alex Herbert wrote:
> On Wed, 12 Jun 2024 at 18:03, Department 8
> wrote:
>
> > Sorry Alex just now saw your email, before sending out the PR!
> >
> > I had done just for isAllEmpty and isAllBlank.
> >
> > Can you tell me more on what can be done, when you said the following:
> >
> > If you are simply negating the result of another method then this use
> case
> > may be better served with addition of a suitable example to the javadoc
> of
> > the method you are negating.
> >
> > Like do you want me to add examples of use-cases?
> >
>
> I've seen the PR. The new methods are a simple boolean negation of existing
> methods. So these are not adding functionality that cannot be achieved with
> the current API.
>
> Note that a quick check in StringUtils for 'return !' finds these methods:
>
> public static boolean isNoneBlank(final CharSequence... css) {
> return !isAnyBlank(css);
> }
>
> public static boolean isNoneEmpty(final CharSequence... css) {
> return !isAnyEmpty(css);
> }
>
> There are two others for single CharSequence args as well: isNotBlank and
> isNotEmpty.
>
> So it is not without precedent to add more methods that are simple
> negations. However we have to consider if this is code bloat, or if the
> addition of simple negation methods is so useful that it warrants
> inclusion. I would currently consider this as redundant given the lack of
> actual logic in the methods.
>
> Alex
>
>
> >
> > On Wed, 12 Jun 2024 at 22:29, Department 8
> > wrote:
> >
> > > I just realized the subject name is bad. But here are the two small
> > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > >
> > > Please find the pull request as here:
> > > https://github.com/apache/commons-lang/pull/1234
> > >
> > > On Wed, 12 Jun 2024 at 21:52, Department 8
> > > wrote:
> > >
> > >> Hey!
> > >>
> > >> Recently when using StringUtils in one of our projects I had felt the
> > >> urgent need to have a utility method like => isAnyNotBlank.
> > >>
> > >> I was able to achieve this using the negation of isAllBlank, so I am
> > >> thinking of introducing the code with all tests.
> > >>
> > >> It is ready to be pushed to PR. Do let me know what you think and what
> > >> are the next steps for the same?
> > >>
> > >>
> > >>
> >
>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
On Wed, 12 Jun 2024 at 18:03, Department 8 wrote:
> Sorry Alex just now saw your email, before sending out the PR!
>
> I had done just for isAllEmpty and isAllBlank.
>
> Can you tell me more on what can be done, when you said the following:
>
> If you are simply negating the result of another method then this use case
> may be better served with addition of a suitable example to the javadoc of
> the method you are negating.
>
> Like do you want me to add examples of use-cases?
>
I've seen the PR. The new methods are a simple boolean negation of existing
methods. So these are not adding functionality that cannot be achieved with
the current API.
Note that a quick check in StringUtils for 'return !' finds these methods:
public static boolean isNoneBlank(final CharSequence... css) {
return !isAnyBlank(css);
}
public static boolean isNoneEmpty(final CharSequence... css) {
return !isAnyEmpty(css);
}
There are two others for single CharSequence args as well: isNotBlank and
isNotEmpty.
So it is not without precedent to add more methods that are simple
negations. However we have to consider if this is code bloat, or if the
addition of simple negation methods is so useful that it warrants
inclusion. I would currently consider this as redundant given the lack of
actual logic in the methods.
Alex
>
> On Wed, 12 Jun 2024 at 22:29, Department 8
> wrote:
>
> > I just realized the subject name is bad. But here are the two small
> > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> >
> > Please find the pull request as here:
> > https://github.com/apache/commons-lang/pull/1234
> >
> > On Wed, 12 Jun 2024 at 21:52, Department 8
> > wrote:
> >
> >> Hey!
> >>
> >> Recently when using StringUtils in one of our projects I had felt the
> >> urgent need to have a utility method like => isAnyNotBlank.
> >>
> >> I was able to achieve this using the negation of isAllBlank, so I am
> >> thinking of introducing the code with all tests.
> >>
> >> It is ready to be pushed to PR. Do let me know what you think and what
> >> are the next steps for the same?
> >>
> >>
> >>
>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
Sorry Alex just now saw your email, before sending out the PR! I had done just for isAllEmpty and isAllBlank. Can you tell me more on what can be done, when you said the following: If you are simply negating the result of another method then this use case may be better served with addition of a suitable example to the javadoc of the method you are negating. Like do you want me to add examples of use-cases? On Wed, 12 Jun 2024 at 22:29, Department 8 wrote: > I just realized the subject name is bad. But here are the two small > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*. > > Please find the pull request as here: > https://github.com/apache/commons-lang/pull/1234 > > On Wed, 12 Jun 2024 at 21:52, Department 8 > wrote: > >> Hey! >> >> Recently when using StringUtils in one of our projects I had felt the >> urgent need to have a utility method like => isAnyNotBlank. >> >> I was able to achieve this using the negation of isAllBlank, so I am >> thinking of introducing the code with all tests. >> >> It is ready to be pushed to PR. Do let me know what you think and what >> are the next steps for the same? >> >> >>
Re: [LANG] Add Any Checks for Not Checks in StringUtils
I just realized the subject name is bad. But here are the two small methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*. Please find the pull request as here: https://github.com/apache/commons-lang/pull/1234 On Wed, 12 Jun 2024 at 21:52, Department 8 wrote: > Hey! > > Recently when using StringUtils in one of our projects I had felt the > urgent need to have a utility method like => isAnyNotBlank. > > I was able to achieve this using the negation of isAllBlank, so I am > thinking of introducing the code with all tests. > > It is ready to be pushed to PR. Do let me know what you think and what are > the next steps for the same? > > >
Re: [LANG] Add Any Checks for Not Checks in StringUtils
Hi,
On Wed, 12 Jun 2024 at 17:23, Department 8 wrote:
> Hey!
>
> Recently when using StringUtils in one of our projects I had felt the
> urgent need to have a utility method like => isAnyNotBlank.
>
> I was able to achieve this using the negation of isAllBlank, so I am
> thinking of introducing the code with all tests.
>
> It is ready to be pushed to PR. Do let me know what you think and what are
> the next steps for the same?
>
Is this different from:
public static boolean isAnyNotBlank(final CharSequence... css) {
return !isAllBlank(css);
}
If the implementation is as above then you add an extra method that must be
invoked using more characters than:
!StringUtils.isAllBlank(...)
This doesn't seem helpful. If there is more logic to the method then it may
be worth considering.
There are also the other methods that could be similarly negated:
isAllEmpty
isAllLowerCase
isAllUpperCase
If you are simply negating the result of another method then this use case
may be better served with addition of a suitable example to the javadoc of
the method you are negating.
Alex
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
Honestly I think not supporting empty literals is just as big a limitation as not supporting single quotes, so IMO we'd just be trading one limitation for another. i.e. if someone were to need empty literals, the things they would have to do to use them are the same things they'd have to do to support single quotes, and I can imagine use cases for both. On Thu, May 30, 2024 at 2:48 PM Gary D. Gregory wrote: > I'm OK with Sebb's solution [1] > > Any further thoughts here? > > Gary > [1] https://github.com/apache/commons-lang/pull/1227 > > On 2024/05/29 13:37:40 Mike Drob wrote: > > On Wed, May 29, 2024 at 8:17 AM Gary Gregory > wrote: > > > > > (Sorry for the top post, phone) > > > > > > A case I can imagine an empty '' occurring is when the format string > itself > > > is built programmatically for example a '%s' or using string > concatenate of > > > a variable that holds a string where that string can be empty or an > "s" to > > > mark a plural or a quote for example. > > > > > > "He said '" + bla + "' to me and I waited mm minutes!" > > > > > > Far fetched? Sure 😀 > > > > > > Gary > > > > > > On Wed, May 29, 2024, 8:43 AM sebb wrote: > > > > > > > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas < > lmous...@gmail.com> > > > > wrote: > > > > > > > > > > > > Hello Gary, > > > > > > > > > > > > Thank you for your response. Some of the new assertions indeed > fail > > > > when interpreting the duplicate single quote as an escaped quote > instead > > > of > > > > a closing and opening quote. In particular, "y' ''years' M 'months'" > is > > > > interpreted as "4 'years 0 months" while the expected text lacks the > > > quote > > > > before "years". Same for "hello''world": it's interpreted as > > > "hello'world" > > > > instead of "helloworld". > > > > > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > > > alternate solution. > > > > > This does not cause issues with any existing tests. > > > > > > > > > > However, it does change the behaviour of a duplicate single quote > > > > > which is found outside an existing opening and closing quote. > > > > > Instead of the empty string, it generates a lone single quote. > > > > > > > > > > Whilst this is a change in behaviour, it seems to me that there > should > > > > > be no need for anyone to use a format that uses a pair of adjacent > > > > > single quotes to generate an empty string in the output, so it > seems > > > > > unlikely that this will cause any breakages. > > > > > > > > I've since realised that this argument could also apply to the > > > > existing test cases: is there really a use-case for adjacent constant > > > > strings? > > > > Why would anyone want to split a constant string in this way? > > > > > > This is similar to allowable string concatenation in Python, which static > > analysis flags as a warning and probable bug. > > > https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > > > > > > > AFAICT it just makes it harder to read the string. > > > > > > > > i.e. do the test cases represent a real-world use case? > > > > > > > > > > I understand this brings forth a breaking change in formats that > use > > > > two single quotes to close and open new literals (or even add an > empty > > > > string), but this is consistent with what java.text.SimpleDateFormat > > > > expects. And I believe that most developers would favor consistency > > > between > > > > format strings in equivalent classes. Thus, I think the cases > described > > > > above where the two single quotes terminate and begin a literal > should no > > > > longer be supported. > > > > > > > > I agree. > > > > > > > > My alternate solution avoids breaking the test cases, but the > downside > > > > is that the syntax is not i
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
I'm OK with Sebb's solution [1] Any further thoughts here? Gary [1] https://github.com/apache/commons-lang/pull/1227 On 2024/05/29 13:37:40 Mike Drob wrote: > On Wed, May 29, 2024 at 8:17 AM Gary Gregory wrote: > > > (Sorry for the top post, phone) > > > > A case I can imagine an empty '' occurring is when the format string itself > > is built programmatically for example a '%s' or using string concatenate of > > a variable that holds a string where that string can be empty or an "s" to > > mark a plural or a quote for example. > > > > "He said '" + bla + "' to me and I waited mm minutes!" > > > > Far fetched? Sure 😀 > > > > Gary > > > > On Wed, May 29, 2024, 8:43 AM sebb wrote: > > > > > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas > > > wrote: > > > > > > > > > > Hello Gary, > > > > > > > > > > Thank you for your response. Some of the new assertions indeed fail > > > when interpreting the duplicate single quote as an escaped quote instead > > of > > > a closing and opening quote. In particular, "y' ''years' M 'months'" is > > > interpreted as "4 'years 0 months" while the expected text lacks the > > quote > > > before "years". Same for "hello''world": it's interpreted as > > "hello'world" > > > instead of "helloworld". > > > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > > alternate solution. > > > > This does not cause issues with any existing tests. > > > > > > > > However, it does change the behaviour of a duplicate single quote > > > > which is found outside an existing opening and closing quote. > > > > Instead of the empty string, it generates a lone single quote. > > > > > > > > Whilst this is a change in behaviour, it seems to me that there should > > > > be no need for anyone to use a format that uses a pair of adjacent > > > > single quotes to generate an empty string in the output, so it seems > > > > unlikely that this will cause any breakages. > > > > > > I've since realised that this argument could also apply to the > > > existing test cases: is there really a use-case for adjacent constant > > > strings? > > > Why would anyone want to split a constant string in this way? > > > This is similar to allowable string concatenation in Python, which static > analysis flags as a warning and probable bug. > https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > > > > AFAICT it just makes it harder to read the string. > > > > > > i.e. do the test cases represent a real-world use case? > > > > > > > > I understand this brings forth a breaking change in formats that use > > > two single quotes to close and open new literals (or even add an empty > > > string), but this is consistent with what java.text.SimpleDateFormat > > > expects. And I believe that most developers would favor consistency > > between > > > format strings in equivalent classes. Thus, I think the cases described > > > above where the two single quotes terminate and begin a literal should no > > > longer be supported. > > > > > > I agree. > > > > > > My alternate solution avoids breaking the test cases, but the downside > > > is that the syntax is not in agreement with > > > java.text.SimpleDateFormat, and is more verbose where a single-quote > > > is to be inserted in an existing constant string (it requires 4 single > > > quotes, rather than 2). > > > > > > > > > > > > > Should this change go forward, I expect it to be part of a major > > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does > > > contain a breaking change. > > > > > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > > > > > Best regards, > > > > > Laertes > > > > > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > > > Hello Laertes, > > > > > > > > > > > > Thank you for your interest in improving Ap
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
On Wed, May 29, 2024 at 8:17 AM Gary Gregory wrote: > (Sorry for the top post, phone) > > A case I can imagine an empty '' occurring is when the format string itself > is built programmatically for example a '%s' or using string concatenate of > a variable that holds a string where that string can be empty or an "s" to > mark a plural or a quote for example. > > "He said '" + bla + "' to me and I waited mm minutes!" > > Far fetched? Sure 😀 > > Gary > > On Wed, May 29, 2024, 8:43 AM sebb wrote: > > > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas > > wrote: > > > > > > > > Hello Gary, > > > > > > > > Thank you for your response. Some of the new assertions indeed fail > > when interpreting the duplicate single quote as an escaped quote instead > of > > a closing and opening quote. In particular, "y' ''years' M 'months'" is > > interpreted as "4 'years 0 months" while the expected text lacks the > quote > > before "years". Same for "hello''world": it's interpreted as > "hello'world" > > instead of "helloworld". > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > alternate solution. > > > This does not cause issues with any existing tests. > > > > > > However, it does change the behaviour of a duplicate single quote > > > which is found outside an existing opening and closing quote. > > > Instead of the empty string, it generates a lone single quote. > > > > > > Whilst this is a change in behaviour, it seems to me that there should > > > be no need for anyone to use a format that uses a pair of adjacent > > > single quotes to generate an empty string in the output, so it seems > > > unlikely that this will cause any breakages. > > > > I've since realised that this argument could also apply to the > > existing test cases: is there really a use-case for adjacent constant > > strings? > > Why would anyone want to split a constant string in this way? This is similar to allowable string concatenation in Python, which static analysis flags as a warning and probable bug. https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > AFAICT it just makes it harder to read the string. > > > > i.e. do the test cases represent a real-world use case? > > > > > > I understand this brings forth a breaking change in formats that use > > two single quotes to close and open new literals (or even add an empty > > string), but this is consistent with what java.text.SimpleDateFormat > > expects. And I believe that most developers would favor consistency > between > > format strings in equivalent classes. Thus, I think the cases described > > above where the two single quotes terminate and begin a literal should no > > longer be supported. > > > > I agree. > > > > My alternate solution avoids breaking the test cases, but the downside > > is that the syntax is not in agreement with > > java.text.SimpleDateFormat, and is more verbose where a single-quote > > is to be inserted in an existing constant string (it requires 4 single > > quotes, rather than 2). > > > > > > > > > > Should this change go forward, I expect it to be part of a major > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does > > contain a breaking change. > > > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > > > Best regards, > > > > Laertes > > > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > > Hello Laertes, > > > > > > > > > > Thank you for your interest in improving Apache Commons Lang :-) > > > > > > > > > > Do you foresee any compatibility issues for existing call sites and > > > > > format strings? > > > > > > > > > > For example, can you make your use cases work and still support: > > > > > > > > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > > > > > Or, should these cases no longer be supported? &
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
(Sorry for the top post, phone) A case I can imagine an empty '' occurring is when the format string itself is built programmatically for example a '%s' or using string concatenate of a variable that holds a string where that string can be empty or an "s" to mark a plural or a quote for example. "He said '" + bla + "' to me and I waited mm minutes!" Far fetched? Sure 😀 Gary On Wed, May 29, 2024, 8:43 AM sebb wrote: > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas > wrote: > > > > > > Hello Gary, > > > > > > Thank you for your response. Some of the new assertions indeed fail > when interpreting the duplicate single quote as an escaped quote instead of > a closing and opening quote. In particular, "y' ''years' M 'months'" is > interpreted as "4 'years 0 months" while the expected text lacks the quote > before "years". Same for "hello''world": it's interpreted as "hello'world" > instead of "helloworld". > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > alternate solution. > > This does not cause issues with any existing tests. > > > > However, it does change the behaviour of a duplicate single quote > > which is found outside an existing opening and closing quote. > > Instead of the empty string, it generates a lone single quote. > > > > Whilst this is a change in behaviour, it seems to me that there should > > be no need for anyone to use a format that uses a pair of adjacent > > single quotes to generate an empty string in the output, so it seems > > unlikely that this will cause any breakages. > > I've since realised that this argument could also apply to the > existing test cases: is there really a use-case for adjacent constant > strings? > Why would anyone want to split a constant string in this way? > AFAICT it just makes it harder to read the string. > > i.e. do the test cases represent a real-world use case? > > > > I understand this brings forth a breaking change in formats that use > two single quotes to close and open new literals (or even add an empty > string), but this is consistent with what java.text.SimpleDateFormat > expects. And I believe that most developers would favor consistency between > format strings in equivalent classes. Thus, I think the cases described > above where the two single quotes terminate and begin a literal should no > longer be supported. > > I agree. > > My alternate solution avoids breaking the test cases, but the downside > is that the syntax is not in agreement with > java.text.SimpleDateFormat, and is more verbose where a single-quote > is to be inserted in an existing constant string (it requires 4 single > quotes, rather than 2). > > > > > > > Should this change go forward, I expect it to be part of a major > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does > contain a breaking change. > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > Best regards, > > > Laertes > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > Hello Laertes, > > > > > > > > Thank you for your interest in improving Apache Commons Lang :-) > > > > > > > > Do you foresee any compatibility issues for existing call sites and > > > > format strings? > > > > > > > > For example, can you make your use cases work and still support: > > > > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > > > Or, should these cases no longer be supported? > > > > > > > > TY! > > > > Gary > > > > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas > wrote: > > > > > > > > > > Greetings, > > > > > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains useful > methods > > > > > to format a duration or period of milliseconds in the textual > > > > > representation given by the format argument. It even allows > arbitrary text > > > > > to be printed between single quotes, on the condition that any > opening > > > > > single quotes will eventually close with another single quo
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
On Sun, 26 May 2024 at 23:37, sebb wrote: > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas wrote: > > > > Hello Gary, > > > > Thank you for your response. Some of the new assertions indeed fail when > > interpreting the duplicate single quote as an escaped quote instead of a > > closing and opening quote. In particular, "y' ''years' M 'months'" is > > interpreted as "4 'years 0 months" while the expected text lacks the quote > > before "years". Same for "hello''world": it's interpreted as "hello'world" > > instead of "helloworld". > > Please see https://github.com/apache/commons-lang/pull/1227 for an > alternate solution. > This does not cause issues with any existing tests. > > However, it does change the behaviour of a duplicate single quote > which is found outside an existing opening and closing quote. > Instead of the empty string, it generates a lone single quote. > > Whilst this is a change in behaviour, it seems to me that there should > be no need for anyone to use a format that uses a pair of adjacent > single quotes to generate an empty string in the output, so it seems > unlikely that this will cause any breakages. I've since realised that this argument could also apply to the existing test cases: is there really a use-case for adjacent constant strings? Why would anyone want to split a constant string in this way? AFAICT it just makes it harder to read the string. i.e. do the test cases represent a real-world use case? > > I understand this brings forth a breaking change in formats that use two > > single quotes to close and open new literals (or even add an empty string), > > but this is consistent with what java.text.SimpleDateFormat expects. And I > > believe that most developers would favor consistency between format strings > > in equivalent classes. Thus, I think the cases described above where the > > two single quotes terminate and begin a literal should no longer be > > supported. I agree. My alternate solution avoids breaking the test cases, but the downside is that the syntax is not in agreement with java.text.SimpleDateFormat, and is more verbose where a single-quote is to be inserted in an existing constant string (it requires 4 single quotes, rather than 2). > > > > Should this change go forward, I expect it to be part of a major release > > (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does contain a > > breaking change. > > > > If you have more questions, please don't hesitate to contact me. > > > > Best regards, > > Laertes > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > Hello Laertes, > > > > > > Thank you for your interest in improving Apache Commons Lang :-) > > > > > > Do you foresee any compatibility issues for existing call sites and > > > format strings? > > > > > > For example, can you make your use cases work and still support: > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > Or, should these cases no longer be supported? > > > > > > TY! > > > Gary > > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas wrote: > > > > > > > > Greetings, > > > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains useful > > > > methods > > > > to format a duration or period of milliseconds in the textual > > > > representation given by the format argument. It even allows arbitrary > > > > text > > > > to be printed between single quotes, on the condition that any opening > > > > single quotes will eventually close with another single quote. > > > > > > > > For example, > > > > DurationFormatUtils.formatDuration(64000L, "mm:ss") > > > > will return "01:04". > > > > > > > > While > > > > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'") > > > > will yield "34min 4sec". > > > > > > > > However, as per the JavaDoc page for this class > > > > <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html> > > > > including > > > > a single quote is currently not supported. Other classes that format > > &
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
On Sun, 26 May 2024 at 08:25, Laertes Moustakas wrote:
>
> Hello Gary,
>
> Thank you for your response. Some of the new assertions indeed fail when
> interpreting the duplicate single quote as an escaped quote instead of a
> closing and opening quote. In particular, "y' ''years' M 'months'" is
> interpreted as "4 'years 0 months" while the expected text lacks the quote
> before "years". Same for "hello''world": it's interpreted as "hello'world"
> instead of "helloworld".
Please see https://github.com/apache/commons-lang/pull/1227 for an
alternate solution.
This does not cause issues with any existing tests.
However, it does change the behaviour of a duplicate single quote
which is found outside an existing opening and closing quote.
Instead of the empty string, it generates a lone single quote.
Whilst this is a change in behaviour, it seems to me that there should
be no need for anyone to use a format that uses a pair of adjacent
single quotes to generate an empty string in the output, so it seems
unlikely that this will cause any breakages.
> I understand this brings forth a breaking change in formats that use two
> single quotes to close and open new literals (or even add an empty string),
> but this is consistent with what java.text.SimpleDateFormat expects. And I
> believe that most developers would favor consistency between format strings
> in equivalent classes. Thus, I think the cases described above where the two
> single quotes terminate and begin a literal should no longer be supported.
>
> Should this change go forward, I expect it to be part of a major release
> (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does contain a
> breaking change.
>
> If you have more questions, please don't hesitate to contact me.
>
> Best regards,
> Laertes
>
> On 2024/05/25 13:47:23 Gary Gregory wrote:
> > Hello Laertes,
> >
> > Thank you for your interest in improving Apache Commons Lang :-)
> >
> > Do you foresee any compatibility issues for existing call sites and
> > format strings?
> >
> > For example, can you make your use cases work and still support:
> >
> > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473
> >
> > Or, should these cases no longer be supported?
> >
> > TY!
> > Gary
> >
> > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas wrote:
> > >
> > > Greetings,
> > >
> > > org.apache.commons.lang3.time.DurationFormatUtils contains useful methods
> > > to format a duration or period of milliseconds in the textual
> > > representation given by the format argument. It even allows arbitrary text
> > > to be printed between single quotes, on the condition that any opening
> > > single quotes will eventually close with another single quote.
> > >
> > > For example,
> > > DurationFormatUtils.formatDuration(64000L, "mm:ss")
> > > will return "01:04".
> > >
> > > While
> > > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'")
> > > will yield "34min 4sec".
> > >
> > > However, as per the JavaDoc page for this class
> > > <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html>
> > > including
> > > a single quote is currently not supported. Other classes that format
> > > datetime such as the java.text.SimpleDateFormat do, by putting two single
> > > quotes next to each other.
> > >
> > > So something like
> > > new SimpleDateFormat("mm'' ss'sec'").format(new Date()); // note the two
> > > single quotes after "mm"
> > > will return something like this:
> > > "42' 02sec"
> > >
> > > Instead,
> > > DurationFormatUtils.formatDuration(64000L, "mm'' ss'sec'")
> > > will return "01 04sec".
> > >
> > > I wish to implement support for single quotes in the DurationFormatUtils
> > > format the same way SimpleDateFormat does; by escaping it with two
> > > consecutive single quote characters. I have searched the mailing list and
> > > found no similar request. I have already tested on the copy of a source
> > > code, including adding tests, and no test throughout the commons-lang
> > > project failed.
> > >
> > > Please let me know if this is an acceptable change, and the next steps to
> > > take should this move forward.
> > >
> > > Best regards,
> > > Laertes Moustakas
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
Hello Gary,
Thank you for your response. Some of the new assertions indeed fail when
interpreting the duplicate single quote as an escaped quote instead of a
closing and opening quote. In particular, "y' ''years' M 'months'" is
interpreted as "4 'years 0 months" while the expected text lacks the quote
before "years". Same for "hello''world": it's interpreted as "hello'world"
instead of "helloworld".
I understand this brings forth a breaking change in formats that use two single
quotes to close and open new literals (or even add an empty string), but this
is consistent with what java.text.SimpleDateFormat expects. And I believe that
most developers would favor consistency between format strings in equivalent
classes. Thus, I think the cases described above where the two single quotes
terminate and begin a literal should no longer be supported.
Should this change go forward, I expect it to be part of a major release (e.g.
version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does contain a breaking
change.
If you have more questions, please don't hesitate to contact me.
Best regards,
Laertes
On 2024/05/25 13:47:23 Gary Gregory wrote:
> Hello Laertes,
>
> Thank you for your interest in improving Apache Commons Lang :-)
>
> Do you foresee any compatibility issues for existing call sites and
> format strings?
>
> For example, can you make your use cases work and still support:
>
> https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473
>
> Or, should these cases no longer be supported?
>
> TY!
> Gary
>
> On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas wrote:
> >
> > Greetings,
> >
> > org.apache.commons.lang3.time.DurationFormatUtils contains useful methods
> > to format a duration or period of milliseconds in the textual
> > representation given by the format argument. It even allows arbitrary text
> > to be printed between single quotes, on the condition that any opening
> > single quotes will eventually close with another single quote.
> >
> > For example,
> > DurationFormatUtils.formatDuration(64000L, "mm:ss")
> > will return "01:04".
> >
> > While
> > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'")
> > will yield "34min 4sec".
> >
> > However, as per the JavaDoc page for this class
> > <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html>
> > including
> > a single quote is currently not supported. Other classes that format
> > datetime such as the java.text.SimpleDateFormat do, by putting two single
> > quotes next to each other.
> >
> > So something like
> > new SimpleDateFormat("mm'' ss'sec'").format(new Date()); // note the two
> > single quotes after "mm"
> > will return something like this:
> > "42' 02sec"
> >
> > Instead,
> > DurationFormatUtils.formatDuration(64000L, "mm'' ss'sec'")
> > will return "01 04sec".
> >
> > I wish to implement support for single quotes in the DurationFormatUtils
> > format the same way SimpleDateFormat does; by escaping it with two
> > consecutive single quote characters. I have searched the mailing list and
> > found no similar request. I have already tested on the copy of a source
> > code, including adding tests, and no test throughout the commons-lang
> > project failed.
> >
> > Please let me know if this is an acceptable change, and the next steps to
> > take should this move forward.
> >
> > Best regards,
> > Laertes Moustakas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
Hello Laertes,
Thank you for your interest in improving Apache Commons Lang :-)
Do you foresee any compatibility issues for existing call sites and
format strings?
For example, can you make your use cases work and still support:
https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473
Or, should these cases no longer be supported?
TY!
Gary
On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas wrote:
>
> Greetings,
>
> org.apache.commons.lang3.time.DurationFormatUtils contains useful methods
> to format a duration or period of milliseconds in the textual
> representation given by the format argument. It even allows arbitrary text
> to be printed between single quotes, on the condition that any opening
> single quotes will eventually close with another single quote.
>
> For example,
> DurationFormatUtils.formatDuration(64000L, "mm:ss")
> will return "01:04".
>
> While
> DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'")
> will yield "34min 4sec".
>
> However, as per the JavaDoc page for this class
> <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html>
> including
> a single quote is currently not supported. Other classes that format
> datetime such as the java.text.SimpleDateFormat do, by putting two single
> quotes next to each other.
>
> So something like
> new SimpleDateFormat("mm'' ss'sec'").format(new Date()); // note the two
> single quotes after "mm"
> will return something like this:
> "42' 02sec"
>
> Instead,
> DurationFormatUtils.formatDuration(64000L, "mm'' ss'sec'")
> will return "01 04sec".
>
> I wish to implement support for single quotes in the DurationFormatUtils
> format the same way SimpleDateFormat does; by escaping it with two
> consecutive single quote characters. I have searched the mailing list and
> found no similar request. I have already tested on the copy of a source
> code, including adding tests, and no test throughout the commons-lang
> project failed.
>
> Please let me know if this is an acceptable change, and the next steps to
> take should this move forward.
>
> Best regards,
> Laertes Moustakas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-lang) branch master updated: Undoing 3322d974876b8d4f934d3544967103ebbcaef726
The build is broken.
This maybe should have been a git revert instead of a plain commit.
Gary
On Wed, May 22, 2024, 2:00 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> jochen pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 9980cf11e Undoing 3322d974876b8d4f934d3544967103ebbcaef726
> 9980cf11e is described below
>
> commit 9980cf11e36ee58bf8556188bf252946f290b6c8
> Author: Jochen Wiedmann
> AuthorDate: Wed May 22 20:00:10 2024 +0200
>
> Undoing 3322d974876b8d4f934d3544967103ebbcaef726
> ---
> src/changes/changes.xml| 1 -
> .../apache/commons/lang3/annotations/Insecure.java | 48 -
> .../org/apache/commons/lang3/annotations/Safe.java | 61
> --
> .../commons/lang3/annotations/package-info.java| 37 -
> 4 files changed, 147 deletions(-)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index b69e1f8a2..34841687a 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -140,7 +140,6 @@ The type attribute can be
> add,update,fix,remove.
> due-to="Dependabot">Bump org.apache.commons:commons-text from 1.11.0 to
> 1.12.0 #1200.
>
> due-to="Paranoïd User">Drop obsolete JDK 13 Maven profile #1142.
> -Added the
> annotations package, including the Insecure, and Safe annotations.
>
>
>
> diff --git
> a/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> b/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> deleted file mode 100644
> index 2802f1189..0
> --- a/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one or more
> - * contributor license agreements. See the NOTICE file distributed with
> - * this work for additional information regarding copyright ownership.
> - * The ASF licenses this file to You under the Apache License, Version 2.0
> - * (the "License"); you may not use this file except in compliance with
> - * the License. You may obtain a copy of the License at
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the License for the specific language governing permissions and
> - * limitations under the License.
> - */
> -package org.apache.commons.lang3.annotations;
> -
> -import java.lang.annotation.Documented;
> -import java.lang.annotation.ElementType;
> -import java.lang.annotation.Retention;
> -import java.lang.annotation.RetentionPolicy;
> -import java.lang.annotation.Target;
> -
> -/**
> - * This annotation is used to indicate, that a constructor, or method
> - * is insecure to use, unless the input parameters contain safe
> ("trusted")
> - * values.
> - *
> - * For example, consider a method like
> - * {@literal @Insecure}
> - * public void runCommand(String pCmdLine) {
> - * }
> - *
> - *
> - * The example method would invoke {@code /bin/sh} (Linux, Unix, or
> MacOS), or
> - * {@code cmd} (Windows) to run an external command, as given by the
> parameter
> - * {@code pCmdLine}. Obviously, depending on the value of the parameter,
> - * this can be dangerous, unless the API user (downstream developer)
> - * knows, that the parameter value is safe (for example, because
> it
> - * is hard coded, or because it has been compared to a white list of
> - * permissible values).
> - */
> -@Retention(RetentionPolicy.RUNTIME)
> -@Target({ElementType.CONSTRUCTOR, ElementType.METHOD})
> -@Documented
> -public @interface Insecure {
> -}
> diff --git a/src/main/java/org/apache/commons/lang3/annotations/Safe.java
> b/src/main/java/org/apache/commons/lang3/annotations/Safe.java
> deleted file mode 100644
> index c3a710cf2..0
> --- a/src/main/java/org/apache/commons/lang3/annotations/Safe.java
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one or more
> - * contributor license agreements. See the NOTICE file distributed with
> - * this work for additional information regarding copyright ownership.
> - * The ASF licenses this file to You under the Apache License, Version 2.0
> - * (the "License"); you may not use this file except in compliance with
> - * the License. You may obtain a copy of the License at
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the
Re: (commons-lang) branch master updated: Adding the @Insecure, and @Safe annotations.
On Fri, 17 May 2024 at 00:11, Gary Gregory wrote:
>
> Can we PLEASE not do this unless we know what the plan is for Commons
> overall? I really don't want to have this stuff copied in all Commons
> Components because I doubt we will want to add Commons Lang as a dependency
> in all Components.
Agreed.
Also if we are to use annotations great care must be taken with the
RetentionPolicy.
Using the wrong setting can mean adding unnecessary runtime
dependencies (this was an issue with the JCIP annotations @ThreadSafe
etc)
> So, what's the plan? Do you plan on copying this stuff
> over and over or depending on Commons Lang all over.
>
> Imaging using code assit and seeing these types being offered from all over
> the place...
And finding they are all slightly different...
>
> Gary
>
> On Thu, May 16, 2024, 6:30 PM wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > jochen pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 3322d9748 Adding the @Insecure, and @Safe annotations.
> > 3322d9748 is described below
> >
> > commit 3322d974876b8d4f934d3544967103ebbcaef726
> > Author: Jochen Wiedmann
> > AuthorDate: Fri May 17 00:28:39 2024 +0200
> >
> > Adding the @Insecure, and @Safe annotations.
> > ---
> > src/changes/changes.xml| 1 +
> > .../apache/commons/lang3/annotations/Insecure.java | 48
> > .../org/apache/commons/lang3/annotations/Safe.java | 61 +++
> > .../commons/lang3/annotations/package-info.java| 37 +++
> > .../commons/lang3/annotations/AnnotationsTest.java | 122
> > +
> > 5 files changed, 269 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index 34841687a..b69e1f8a2 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -140,6 +140,7 @@ The type attribute can be
> > add,update,fix,remove.
> > > due-to="Dependabot">Bump org.apache.commons:commons-text from 1.11.0 to
> > 1.12.0 #1200.
> >
> > > due-to="Paranoïd User">Drop obsolete JDK 13 Maven profile #1142.
> > +Added the
> > annotations package, including the Insecure, and Safe annotations.
> >
> >
> >
> > diff --git
> > a/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> > b/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> > new file mode 100644
> > index 0..2802f1189
> > --- /dev/null
> > +++ b/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> > @@ -0,0 +1,48 @@
> > +/*
> > + * Licensed to the Apache Software Foundation (ASF) under one or more
> > + * contributor license agreements. See the NOTICE file distributed with
> > + * this work for additional information regarding copyright ownership.
> > + * The ASF licenses this file to You under the Apache License, Version 2.0
> > + * (the "License"); you may not use this file except in compliance with
> > + * the License. You may obtain a copy of the License at
> > + *
> > + * http://www.apache.org/licenses/LICENSE-2.0
> > + *
> > + * Unless required by applicable law or agreed to in writing, software
> > + * distributed under the License is distributed on an "AS IS" BASIS,
> > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > + * See the License for the specific language governing permissions and
> > + * limitations under the License.
> > + */
> > +package org.apache.commons.lang3.annotations;
> > +
> > +import java.lang.annotation.Documented;
> > +import java.lang.annotation.ElementType;
> > +import java.lang.annotation.Retention;
> > +import java.lang.annotation.RetentionPolicy;
> > +import java.lang.annotation.Target;
> > +
> > +/**
> > + * This annotation is used to indicate, that a constructor, or method
> > + * is insecure to use, unless the input parameters contain safe
> > ("trusted")
> > + * values.
> > + *
> > + * For example, consider a method like
> > + * {@literal @Insecure}
> > + * public void runCommand(String pCmdLine) {
> > + * }
> > + *
> > + *
> > + * The example method would invoke {@code /bin/sh} (Linux, Unix, or
> > MacOS), or
> > + * {@code cmd} (Windows) to run an e
Re: (commons-lang) branch master updated: Adding the @Insecure, and @Safe annotations.
Can we PLEASE not do this unless we know what the plan is for Commons
overall? I really don't want to have this stuff copied in all Commons
Components because I doubt we will want to add Commons Lang as a dependency
in all Components. So, what's the plan? Do you plan on copying this stuff
over and over or depending on Commons Lang all over.
Imaging using code assit and seeing these types being offered from all over
the place...
Gary
Gary
On Thu, May 16, 2024, 6:30 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> jochen pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 3322d9748 Adding the @Insecure, and @Safe annotations.
> 3322d9748 is described below
>
> commit 3322d974876b8d4f934d3544967103ebbcaef726
> Author: Jochen Wiedmann
> AuthorDate: Fri May 17 00:28:39 2024 +0200
>
> Adding the @Insecure, and @Safe annotations.
> ---
> src/changes/changes.xml| 1 +
> .../apache/commons/lang3/annotations/Insecure.java | 48
> .../org/apache/commons/lang3/annotations/Safe.java | 61 +++
> .../commons/lang3/annotations/package-info.java| 37 +++
> .../commons/lang3/annotations/AnnotationsTest.java | 122
> +
> 5 files changed, 269 insertions(+)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 34841687a..b69e1f8a2 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -140,6 +140,7 @@ The type attribute can be
> add,update,fix,remove.
> due-to="Dependabot">Bump org.apache.commons:commons-text from 1.11.0 to
> 1.12.0 #1200.
>
> due-to="Paranoïd User">Drop obsolete JDK 13 Maven profile #1142.
> +Added the
> annotations package, including the Insecure, and Safe annotations.
>
>
>
> diff --git
> a/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> b/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> new file mode 100644
> index 0..2802f1189
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/lang3/annotations/Insecure.java
> @@ -0,0 +1,48 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.commons.lang3.annotations;
> +
> +import java.lang.annotation.Documented;
> +import java.lang.annotation.ElementType;
> +import java.lang.annotation.Retention;
> +import java.lang.annotation.RetentionPolicy;
> +import java.lang.annotation.Target;
> +
> +/**
> + * This annotation is used to indicate, that a constructor, or method
> + * is insecure to use, unless the input parameters contain safe
> ("trusted")
> + * values.
> + *
> + * For example, consider a method like
> + * {@literal @Insecure}
> + * public void runCommand(String pCmdLine) {
> + * }
> + *
> + *
> + * The example method would invoke {@code /bin/sh} (Linux, Unix, or
> MacOS), or
> + * {@code cmd} (Windows) to run an external command, as given by the
> parameter
> + * {@code pCmdLine}. Obviously, depending on the value of the parameter,
> + * this can be dangerous, unless the API user (downstream developer)
> + * knows, that the parameter value is safe (for example, because
> it
> + * is hard coded, or because it has been compared to a white list of
> + * permissible values).
> + */
> +@Retention(RetentionPolicy.RUNTIME)
> +@Target({ElementType.CONSTRUCTOR, ElementType.METHOD})
> +@Documented
> +public @interface Insecure {
> +}
> diff --git a/src/main/java/org/apache/commons/lang3/annotations/Safe.java
> b/src/main/java/org/apache/commons/lang3/annotations/Safe.java
> new file mode 100644
> index 0..4b5212c71
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/lang3/annotat
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
I meant I'll only change the Suppliers to Strings. The deprecations are fine
IMO. This is how I see it:
- Stock system property access is done through SystemProperties (you get
Strings)
- More advanced services that require conversions like getting a Stream of
Paths for a java.class.path is done elsewhere.
- For example, SystemUtils gives you the 'user.home' string as a File belongs
where it is now: File file = SystemUtils.getUserHome(). I don't think we need a
User class for example.
Gary
On 2024/05/02 18:57:04 "Gary D. Gregory" wrote:
> Hi Bernd,
>
> Sounds reasonable. I'll revert the deprecation and use String defaults
> instead of Suppliers.
>
> Gary
>
> On 2024/05/01 17:56:34 Bernd Eckenfels wrote:
> > Hi Gregory,
> >
> > What’s the idea behind that deprecation? The implementation is robust and
> > simple and easy to use. I would guess most user rather want to specify a
> > literal fallback than a supplier.
> >
> > Gruss
> > Bernd
> >
> > ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > ggregory pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> > >
> > > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > > Author: Gary Gregory
> > > AuthorDate: Wed May 1 09:12:09 2024 -0400
> > >
> > > Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier)
> > > ---
> > > src/changes/changes.xml | 1 +
> > > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > > 2 files changed, 4 insertions(+)
> > >
> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > > index cdd3a0cd0..1d896a999 100644
> > > --- a/src/changes/changes.xml
> > > +++ b/src/changes/changes.xml
> > > @@ -123,6 +123,7 @@ The type attribute can be
> > > add,update,fix,remove.
> > > Fix Java version in README.md #1170.
> > > StringUtils.stripAccents() should handle
> > > ligatures, UTF32 math blocks, etc. #1201.
> > > > > due-to="kijong.youn, Aakash Gupta, Gary
> > > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > > class in the inner class parameterized enclosing class #657.
> > > +Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier).
> > >
> > > > > due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > > > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > > 3.1.1 to 3.2.0 #1175.
> > > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > index cbb4721fb..8044fd4b0 100644
> > > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > @@ -17,6 +17,7 @@
> > > package org.apache.commons.lang3;
> > >
> > > import java.io.File;
> > > +import java.util.function.Supplier;
> > >
> > > /**
> > > * Helpers for {@link System}.
> > > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > > * access to the specified system property.
> > > * @see SystemProperties#getUserName()
> > > * @since 3.10
> > > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > > */
> > > +@Deprecated
> > > public static String getUserName(final String defaultValue) {
> > > return System.getProperty(SystemProperties.USER_NAME,
> > > defaultValue);
> > > }
> > >
> > >
> >
> >
> > Gruß
> > Bernd
> > —
> > https://bernd.eckenfels.net
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
Hello Elliotte,
OK, I'll use String defaults instead of Suppliers.
Gary
On 2024/05/02 16:48:48 Elliotte Rusty Harold wrote:
> I'm OK with preferring SystemProperties though I'm not sure that
> alpine justifies a new method and deprecation.
>
> I second the opinion that a literal string is strongly preferable to a
> Supplier here. Pick the simplest thing that could possibly work. As
> Knuth warned us, premature optimization is the root of all evil in
> programming.
>
> On Wed, May 1, 2024 at 1:56 PM Bernd Eckenfels wrote:
> >
> > Hi Gregory,
> >
> > What’s the idea behind that deprecation? The implementation is robust and
> > simple and easy to use. I would guess most user rather want to specify a
> > literal fallback than a supplier.
> >
> > Gruss
> > Bernd
> >
> > ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > ggregory pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> > >
> > > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > > Author: Gary Gregory
> > > AuthorDate: Wed May 1 09:12:09 2024 -0400
> > >
> > > Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier)
> > > ---
> > > src/changes/changes.xml | 1 +
> > > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > > 2 files changed, 4 insertions(+)
> > >
> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > > index cdd3a0cd0..1d896a999 100644
> > > --- a/src/changes/changes.xml
> > > +++ b/src/changes/changes.xml
> > > @@ -123,6 +123,7 @@ The type attribute can be
> > > add,update,fix,remove.
> > > Fix Java version in README.md #1170.
> > > StringUtils.stripAccents() should handle
> > > ligatures, UTF32 math blocks, etc. #1201.
> > > > > due-to="kijong.youn, Aakash Gupta, Gary
> > > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > > class in the inner class parameterized enclosing class #657.
> > > +Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier).
> > >
> > > > > due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > > > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > > 3.1.1 to 3.2.0 #1175.
> > > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > index cbb4721fb..8044fd4b0 100644
> > > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > @@ -17,6 +17,7 @@
> > > package org.apache.commons.lang3;
> > >
> > > import java.io.File;
> > > +import java.util.function.Supplier;
> > >
> > > /**
> > > * Helpers for {@link System}.
> > > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > > * access to the specified system property.
> > > * @see SystemProperties#getUserName()
> > > * @since 3.10
> > > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > > */
> > > +@Deprecated
> > > public static String getUserName(final String defaultValue) {
> > > return System.getProperty(SystemProperties.USER_NAME,
> > > defaultValue);
> > > }
> > >
> > >
> >
> >
> > Gruß
> > Bernd
> > —
> > https://bernd.eckenfels.net
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
Hi Bernd,
Sounds reasonable. I'll revert the deprecation and use String defaults instead
of Suppliers.
Gary
On 2024/05/01 17:56:34 Bernd Eckenfels wrote:
> Hi Gregory,
>
> What’s the idea behind that deprecation? The implementation is robust and
> simple and easy to use. I would guess most user rather want to specify a
> literal fallback than a supplier.
>
> Gruss
> Bernd
>
> ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > Author: Gary Gregory
> > AuthorDate: Wed May 1 09:12:09 2024 -0400
> >
> > Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier)
> > ---
> > src/changes/changes.xml | 1 +
> > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index cdd3a0cd0..1d896a999 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -123,6 +123,7 @@ The type attribute can be
> > add,update,fix,remove.
> > Fix Java version in README.md #1170.
> > StringUtils.stripAccents() should handle
> > ligatures, UTF32 math blocks, etc. #1201.
> > > due-to="kijong.youn, Aakash Gupta, Gary
> > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > class in the inner class parameterized enclosing class #657.
> > +Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier).
> >
> > > due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > 3.1.1 to 3.2.0 #1175.
> > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > index cbb4721fb..8044fd4b0 100644
> > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > @@ -17,6 +17,7 @@
> > package org.apache.commons.lang3;
> >
> > import java.io.File;
> > +import java.util.function.Supplier;
> >
> > /**
> > * Helpers for {@link System}.
> > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > * access to the specified system property.
> > * @see SystemProperties#getUserName()
> > * @since 3.10
> > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > */
> > +@Deprecated
> > public static String getUserName(final String defaultValue) {
> > return System.getProperty(SystemProperties.USER_NAME,
> > defaultValue);
> > }
> >
> >
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
I'm OK with preferring SystemProperties though I'm not sure that
alpine justifies a new method and deprecation.
I second the opinion that a literal string is strongly preferable to a
Supplier here. Pick the simplest thing that could possibly work. As
Knuth warned us, premature optimization is the root of all evil in
programming.
On Wed, May 1, 2024 at 1:56 PM Bernd Eckenfels wrote:
>
> Hi Gregory,
>
> What’s the idea behind that deprecation? The implementation is robust and
> simple and easy to use. I would guess most user rather want to specify a
> literal fallback than a supplier.
>
> Gruss
> Bernd
>
> ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > Author: Gary Gregory
> > AuthorDate: Wed May 1 09:12:09 2024 -0400
> >
> > Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier)
> > ---
> > src/changes/changes.xml | 1 +
> > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index cdd3a0cd0..1d896a999 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -123,6 +123,7 @@ The type attribute can be
> > add,update,fix,remove.
> > Fix Java version in README.md #1170.
> > StringUtils.stripAccents() should handle
> > ligatures, UTF32 math blocks, etc. #1201.
> > > due-to="kijong.youn, Aakash Gupta, Gary
> > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > class in the inner class parameterized enclosing class #657.
> > +Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier).
> >
> > > due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > 3.1.1 to 3.2.0 #1175.
> > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > index cbb4721fb..8044fd4b0 100644
> > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > @@ -17,6 +17,7 @@
> > package org.apache.commons.lang3;
> >
> > import java.io.File;
> > +import java.util.function.Supplier;
> >
> > /**
> > * Helpers for {@link System}.
> > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > * access to the specified system property.
> > * @see SystemProperties#getUserName()
> > * @since 3.10
> > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > */
> > +@Deprecated
> > public static String getUserName(final String defaultValue) {
> > return System.getProperty(SystemProperties.USER_NAME,
> > defaultValue);
> > }
> >
> >
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
It feels like the supplier version is much better to avoid the use case of
building the string in place.
I would also like to centralize all things related directly to sys props in
the SysProp class. This way, you know to look in one place instead of
sometimes here and sometimes there.
Do you think we need both versions of the API?
Gary
On Wed, May 1, 2024, 1:56 PM Bernd Eckenfels wrote:
> Hi Gregory,
>
> What’s the idea behind that deprecation? The implementation is robust and
> simple and easy to use. I would guess most user rather want to specify a
> literal fallback than a supplier.
>
> Gruss
> Bernd
>
> ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > Author: Gary Gregory
> > AuthorDate: Wed May 1 09:12:09 2024 -0400
> >
> > Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier)
> > ---
> > src/changes/changes.xml | 1 +
> > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index cdd3a0cd0..1d896a999 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -123,6 +123,7 @@ The type attribute can be
> > add,update,fix,remove.
> > Fix Java version in README.md #1170.
> > StringUtils.stripAccents() should
> handle
> > ligatures, UTF32 math blocks, etc. #1201.
> > > due-to="kijong.youn, Aakash Gupta, Gary
> > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > class in the inner class parameterized enclosing class
> #657.
> > +Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier).
> >
> > > due-to="Dependabot">Bump commons-parent from 64 to 69
> #1194.
> > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > 3.1.1 to 3.2.0 #1175.
> > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > index cbb4721fb..8044fd4b0 100644
> > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > @@ -17,6 +17,7 @@
> > package org.apache.commons.lang3;
> >
> > import java.io.File;
> > +import java.util.function.Supplier;
> >
> > /**
> > * Helpers for {@link System}.
> > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > * access to the specified system property.
> > * @see SystemProperties#getUserName()
> > * @since 3.10
> > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > */
> > +@Deprecated
> > public static String getUserName(final String defaultValue) {
> > return System.getProperty(SystemProperties.USER_NAME,
> > defaultValue);
> > }
> >
> >
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
Hi Gregory,
What’s the idea behind that deprecation? The implementation is robust and
simple and easy to use. I would guess most user rather want to specify a
literal fallback than a supplier.
Gruss
Bernd
ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
> commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> Author: Gary Gregory
> AuthorDate: Wed May 1 09:12:09 2024 -0400
>
> Deprecate SystemUtils.getUserName(String) in favor of
> SystemProperties.getUserName(Supplier)
> ---
> src/changes/changes.xml | 1 +
> src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index cdd3a0cd0..1d896a999 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -123,6 +123,7 @@ The type attribute can be
> add,update,fix,remove.
> Fix Java version in README.md #1170.
> StringUtils.stripAccents() should handle
> ligatures, UTF32 math blocks, etc. #1201.
>due-to="kijong.youn, Aakash Gupta, Gary
> Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> class in the inner class parameterized enclosing class #657.
> +Deprecate SystemUtils.getUserName(String) in favor of
> SystemProperties.getUserName(Supplier).
>
>due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
>due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> 3.1.1 to 3.2.0 #1175.
> diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> index cbb4721fb..8044fd4b0 100644
> --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> @@ -17,6 +17,7 @@
> package org.apache.commons.lang3;
>
> import java.io.File;
> +import java.util.function.Supplier;
>
> /**
> * Helpers for {@link System}.
> @@ -2041,7 +2042,9 @@ public class SystemUtils {
> * access to the specified system property.
> * @see SystemProperties#getUserName()
> * @since 3.10
> + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> */
> +@Deprecated
> public static String getUserName(final String defaultValue) {
> return System.getProperty(SystemProperties.USER_NAME,
> defaultValue);
> }
>
>
Gruß
Bernd
—
https://bernd.eckenfels.net
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
gggests to use trySetAccessible. But I fear that will still do nothing
>> and you won't get access to those inner knowledge inside
>> java.util.LinkedList etc.
>>>>>>
>>>>>> And using equals() on the List sadly won't help either, as the
>> SomeInnerDTO would also get compared with equals(), but that will obviously
>> use identity comparison only :(
>>>>>>
>>>>>>
>>>>>> What I did for now (running all tests with a few projects right now,
>> but looks promising):
>>>>>>
>>>>>> diff --git
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>>> index ff5276b04..cf878da40 100644
>>>>>> ---
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>>> +++
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final
>> Object lhs, final Object rhs) {
>>>>>> if (bypassReflectionClasses != null
>>>>>> && (bypassReflectionClasses.contains(lhsClass) ||
>> bypassReflectionClasses.contains(rhsClass))) {
>>>>>> isEquals = lhs.equals(rhs);
>>>>>> +} else if (testClass.isAssignableFrom(List.class)) {
>>>>>> +List lList = (List) lhs;
>>>>>> +List rList = (List) rhs;
>>>>>> +if (lList.size() != rList.size()) {
>>>>>> +isEquals = false;
>>>>>> +return this;
>>>>>> +}
>>>>>> +for (int i = 0; i < lList.size(); i++) {
>>>>>> +reflectionAppend(lList.get(i), rList.get(i));
>>>>>> +}
>>>>>> } else {
>>>>>>
>>>>>> I'm rather sure this is still not enough and there are plenty other
>> cases to consider. Like e.g. handling Maps etc.
>>>>>> But at least that's the direction I try to approach it right now. And
>> of course this new part should potentially also be enabled by a flag...
>>>>>>
>>>>>> Will keep you updated.
>>>>>>
>>>>>> txs and LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/LANG-1711
>>>>>>
>>>>>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory >> :
>>>>>>>
>>>>>>> This sounds like a good idea to try. I would call the option
>> something else
>>>>>>> though. We would not skip calling equals if it is defined right? How
>> about
>>>>>>> "useEqualsIfPresent".
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg >>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9
>> onwards
>>>>>>>> we get more and more nasty module problems. Mainly because the code
>> tries
>>>>>>>> to recurse into java.util.* classes as well.
>>>>>>>> I know that I can use setBypassReflectionClasses for those. But
>> wouldn't
>>>>>>>> it be fine to have an additional switch to 'skipOnCustomEquals' or
>> similar?
>>>>>>>>
>>>>>>>> The idea is to only use reflection on classes which do not provide
>> their
>>>>>>>> own equals method. One can test this imo rather easily by checking
>> whether
>>>>>>>> classInQuestion.getMethod("equals",
>> Object.class).getDeclaringClass() !=
>>>>>>>> Object.class
>>>>>>>> Do that for lhs and rhs and if both fit the criteria -> invoke
>> equals
>>>>>>>>
>>>>>>>> Wdyt of that idea? Worth trying or is there already a better
>> solution?
>>>>>>>> With the new flag we can make sure that we do not change the current
>>>>>>>> behaviour for existing use cases.
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> -
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > dev-unsubscr...@commons.apache.org>
>>>> For additional commands, e-mail: dev-h...@commons.apache.org > dev-h...@commons.apache.org>
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > dev-unsubscr...@commons.apache.org>
>>> For additional commands, e-mail: dev-h...@commons.apache.org > dev-h...@commons.apache.org>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
ilder/EqualsBuilder.java
> >>>> index ff5276b04..cf878da40 100644
> >>>> ---
> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >>>> +++
> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >>>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final
> Object lhs, final Object rhs) {
> >>>>if (bypassReflectionClasses != null
> >>>>&& (bypassReflectionClasses.contains(lhsClass) ||
> bypassReflectionClasses.contains(rhsClass))) {
> >>>>isEquals = lhs.equals(rhs);
> >>>> +} else if (testClass.isAssignableFrom(List.class)) {
> >>>> +List lList = (List) lhs;
> >>>> +List rList = (List) rhs;
> >>>> +if (lList.size() != rList.size()) {
> >>>> +isEquals = false;
> >>>> +return this;
> >>>> +}
> >>>> +for (int i = 0; i < lList.size(); i++) {
> >>>> +reflectionAppend(lList.get(i), rList.get(i));
> >>>> +}
> >>>>} else {
> >>>>
> >>>> I'm rather sure this is still not enough and there are plenty other
> cases to consider. Like e.g. handling Maps etc.
> >>>> But at least that's the direction I try to approach it right now. And
> of course this new part should potentially also be enabled by a flag...
> >>>>
> >>>> Will keep you updated.
> >>>>
> >>>> txs and LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/LANG-1711
> >>>>
> >>>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory >:
> >>>>>
> >>>>> This sounds like a good idea to try. I would call the option
> something else
> >>>>> though. We would not skip calling equals if it is defined right? How
> about
> >>>>> "useEqualsIfPresent".
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg >
> >>>>> wrote:
> >>>>>
> >>>>>> Hi!
> >>>>>>
> >>>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9
> onwards
> >>>>>> we get more and more nasty module problems. Mainly because the code
> tries
> >>>>>> to recurse into java.util.* classes as well.
> >>>>>> I know that I can use setBypassReflectionClasses for those. But
> wouldn't
> >>>>>> it be fine to have an additional switch to 'skipOnCustomEquals' or
> similar?
> >>>>>>
> >>>>>> The idea is to only use reflection on classes which do not provide
> their
> >>>>>> own equals method. One can test this imo rather easily by checking
> whether
> >>>>>> classInQuestion.getMethod("equals",
> Object.class).getDeclaringClass() !=
> >>>>>> Object.class
> >>>>>> Do that for lhs and rhs and if both fit the criteria -> invoke
> equals
> >>>>>>
> >>>>>> Wdyt of that idea? Worth trying or is there already a better
> solution?
> >>>>>> With the new flag we can make sure that we do not change the current
> >>>>>> behaviour for existing use cases.
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> -
> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org dev-unsubscr...@commons.apache.org>
> >> For additional commands, e-mail: dev-h...@commons.apache.org dev-h...@commons.apache.org>
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org dev-unsubscr...@commons.apache.org>
> > For additional commands, e-mail: dev-h...@commons.apache.org dev-h...@commons.apache.org>
>
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
ff5276b04..cf878da40 100644
>>>>> ---
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>> +++
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final
>> Object lhs, final Object rhs) {
>>>>>if (bypassReflectionClasses != null
>>>>>&& (bypassReflectionClasses.contains(lhsClass) ||
>> bypassReflectionClasses.contains(rhsClass))) {
>>>>>isEquals = lhs.equals(rhs);
>>>>> +} else if (testClass.isAssignableFrom(List.class)) {
>>>>> +List lList = (List) lhs;
>>>>> +List rList = (List) rhs;
>>>>> +if (lList.size() != rList.size()) {
>>>>> +isEquals = false;
>>>>> +return this;
>>>>> +}
>>>>> +for (int i = 0; i < lList.size(); i++) {
>>>>> +reflectionAppend(lList.get(i), rList.get(i));
>>>>> +}
>>>>>} else {
>>>>>
>>>>> I'm rather sure this is still not enough and there are plenty other
>> cases to consider. Like e.g. handling Maps etc.
>>>>> But at least that's the direction I try to approach it right now. And
>> of course this new part should potentially also be enabled by a flag...
>>>>>
>>>>> Will keep you updated.
>>>>>
>>>>> txs and LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/LANG-1711
>>>>>
>>>>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory >> :
>>>>>>
>>>>>> This sounds like a good idea to try. I would call the option
>> something else
>>>>>> though. We would not skip calling equals if it is defined right? How
>> about
>>>>>> "useEqualsIfPresent".
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg >>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9
>> onwards
>>>>>>> we get more and more nasty module problems. Mainly because the code
>> tries
>>>>>>> to recurse into java.util.* classes as well.
>>>>>>> I know that I can use setBypassReflectionClasses for those. But
>> wouldn't
>>>>>>> it be fine to have an additional switch to 'skipOnCustomEquals' or
>> similar?
>>>>>>>
>>>>>>> The idea is to only use reflection on classes which do not provide
>> their
>>>>>>> own equals method. One can test this imo rather easily by checking
>> whether
>>>>>>> classInQuestion.getMethod("equals",
>> Object.class).getDeclaringClass() !=
>>>>>>> Object.class
>>>>>>> Do that for lhs and rhs and if both fit the criteria -> invoke
>> equals
>>>>>>>
>>>>>>> Wdyt of that idea? Worth trying or is there already a better
>> solution?
>>>>>>> With the new flag we can make sure that we do not change the current
>>>>>>> behaviour for existing use cases.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>> -
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
ect rhs) {
>>>>if (bypassReflectionClasses != null
>>>>&& (bypassReflectionClasses.contains(lhsClass) ||
>>>> bypassReflectionClasses.contains(rhsClass))) {
>>>>isEquals = lhs.equals(rhs);
>>>> +} else if (testClass.isAssignableFrom(List.class)) {
>>>> + List lList = (List) lhs;
>>>> +List rList = (List) rhs;
>>>> +if (lList.size() != rList.size()) {
>>>> +isEquals = false;
>>>> +return this;
>>>> +}
>>>> +for (int i = 0; i < lList.size(); i++) {
>>>> +reflectionAppend(lList.get(i), rList.get(i));
>>>> +}
>>>>} else {
>>>>
>>>> I'm rather sure this is still not enough and there are plenty other cases
>>>> to consider. Like e.g. handling Maps etc.
>>>> But at least that's the direction I try to approach it right now. And of
>>>> course this new part should potentially also be enabled by a flag...
>>>>
>>>> Will keep you updated.
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/LANG-1711
>>>>
>>>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
>>>>>
>>>>> This sounds like a good idea to try. I would call the option something
>>>>> else
>>>>> though. We would not skip calling equals if it is defined right? How about
>>>>> "useEqualsIfPresent".
>>>>>
>>>>> Gary
>>>>>
>>>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
>>>>> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9
>>>>>> onwards
>>>>>> we get more and more nasty module problems. Mainly because the code tries
>>>>>> to recurse into java.util.* classes as well.
>>>>>> I know that I can use setBypassReflectionClasses for those. But wouldn't
>>>>>> it be fine to have an additional switch to 'skipOnCustomEquals' or
>>>>>> similar?
>>>>>>
>>>>>> The idea is to only use reflection on classes which do not provide their
>>>>>> own equals method. One can test this imo rather easily by checking
>>>>>> whether
>>>>>> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
>>>>>> Object.class
>>>>>> Do that for lhs and rhs and if both fit the criteria -> invoke equals
>>>>>>
>>>>>> Wdyt of that idea? Worth trying or is there already a better solution?
>>>>>> With the new flag we can make sure that we do not change the current
>>>>>> behaviour for existing use cases.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> <mailto:dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> <mailto:dev-h...@commons.apache.org>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
> <mailto:dev-h...@commons.apache.org>
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
ass)) {
> > >> +List lList = (List) lhs;
> > >> +List rList = (List) rhs;
> > >> +if (lList.size() != rList.size()) {
> > >> +isEquals = false;
> > >> +return this;
> > >> +}
> > >> +for (int i = 0; i < lList.size(); i++) {
> > >> +reflectionAppend(lList.get(i), rList.get(i));
> > >> +}
> > >> } else {
> > >>
> > >> I'm rather sure this is still not enough and there are plenty other
> cases to consider. Like e.g. handling Maps etc.
> > >> But at least that's the direction I try to approach it right now. And
> of course this new part should potentially also be enabled by a flag...
> > >>
> > >> Will keep you updated.
> > >>
> > >> txs and LieGrue,
> > >> strub
> > >>
> > >>
> > >> [1] https://issues.apache.org/jira/browse/LANG-1711
> > >>
> > >>> Am 06.03.2024 um 13:18 schrieb Gary Gregory >:
> > >>>
> > >>> This sounds like a good idea to try. I would call the option
> something else
> > >>> though. We would not skip calling equals if it is defined right? How
> about
> > >>> "useEqualsIfPresent".
> > >>>
> > >>> Gary
> > >>>
> > >>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg >
> > >>> wrote:
> > >>>
> > >>>> Hi!
> > >>>>
> > >>>> I have a question about EqualsBuilder#reflectionEquals. From Java9
> onwards
> > >>>> we get more and more nasty module problems. Mainly because the code
> tries
> > >>>> to recurse into java.util.* classes as well.
> > >>>> I know that I can use setBypassReflectionClasses for those. But
> wouldn't
> > >>>> it be fine to have an additional switch to 'skipOnCustomEquals' or
> similar?
> > >>>>
> > >>>> The idea is to only use reflection on classes which do not provide
> their
> > >>>> own equals method. One can test this imo rather easily by checking
> whether
> > >>>> classInQuestion.getMethod("equals",
> Object.class).getDeclaringClass() !=
> > >>>> Object.class
> > >>>> Do that for lhs and rhs and if both fit the criteria -> invoke
> equals
> > >>>>
> > >>>> Wdyt of that idea? Worth trying or is there already a better
> solution?
> > >>>> With the new flag we can make sure that we do not change the current
> > >>>> behaviour for existing use cases.
> > >>>>
> > >>>> LieGrue,
> > >>>> strub
> > >>>>
> > >>>>
> > >>>>
> -
> > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>>>
> > >>>>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
On 2024/03/07 06:58:30 Mark Struberg wrote:
> The question to me is how we can make it more robust.
> In a Collection (but actually also in most lists) the order in which you get
> the values (Iterator or get(i)) is not deterministic. It can be different in
> one list than in another - even if they contain the exact same items.
Hm, so to iterate through Lists in parallel would work but not with Sets.
>
> Not yet sure how to work around this. We can probably try to sort it first,
> but then again, if they do not implement Comparable it won't help much. Or do
> a containsElement based on reflection as well - but that would be rather slow.
This is one of those: If you want support for the feature, it'll work, but
it'll be slow because there is no other way to do it (for now if ever).
Gary
>
> Same with Maps. There is a good reason why the key at least should implement
> equals/hashCode. If this is not the case, then we are not able to implement
> this properly I fear.
>
> Any ideas?
>
> LieGrue,
> strub
>
> > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> >
> > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> >
> > For the diff, I'd suggest you test and iterable over a Collection
> > instead of a List.
> >
> > Then you'd need a separate test and traversal for Map instances.
> >
> > (Still no common super-interface in Java 21 for Collections and Maps...)
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> > wrote:
> >>
> >> Hi Gregory!
> >>
> >> I did try this out and figured that I didn't think it though. Maybe I need
> >> to go a few steps back and explain the problem:
> >>
> >> I have the following constellation
> >>
> >> public class SomeInnerDTO {int field..} // NOT implements equals!
> >> public class TheOuterDTO{ List innerList;..}
> >>
> >> My problem is that reflectionEquals (which I use in a unit test) tries to
> >> introspect fields even in java.util.classes. And for getting the values of
> >> those classes it tries to call a setAccessible(true);
> >> And obviously here it fails. There is a ticket already open [1] which
> >> sugggests to use trySetAccessible. But I fear that will still do nothing
> >> and you won't get access to those inner knowledge inside
> >> java.util.LinkedList etc.
> >>
> >> And using equals() on the List sadly won't help either, as the
> >> SomeInnerDTO would also get compared with equals(), but that will
> >> obviously use identity comparison only :(
> >>
> >>
> >> What I did for now (running all tests with a few projects right now, but
> >> looks promising):
> >>
> >> diff --git
> >> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> index ff5276b04..cf878da40 100644
> >> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object
> >> lhs, final Object rhs) {
> >> if (bypassReflectionClasses != null
> >> && (bypassReflectionClasses.contains(lhsClass) ||
> >> bypassReflectionClasses.contains(rhsClass))) {
> >> isEquals = lhs.equals(rhs);
> >> +} else if (testClass.isAssignableFrom(List.class)) {
> >> +List lList = (List) lhs;
> >> +List rList = (List) rhs;
> >> +if (lList.size() != rList.size()) {
> >> +isEquals = false;
> >> +return this;
> >> + }
> >> +for (int i = 0; i < lList.size(); i++) {
> >> +reflectionAppend(lList.get(i), rList.get(i));
> >> +}
> >> } else {
> >>
> >> I'm rather sure this is still not enough and there are plenty other cases
> >> to consider. Like e.g. handling Maps etc.
> >> But at least that's the direction I try to approach it right now. And of
> >> course this new part should potentially also be enabled by a flag...
> >>
> >> Will keep you updated.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
Could one calculate the hashes for each entry, sort them, and then
generate the hash for the collection?
On Thu, 7 Mar 2024 at 06:59, Mark Struberg wrote:
>
> The question to me is how we can make it more robust.
> In a Collection (but actually also in most lists) the order in which you get
> the values (Iterator or get(i)) is not deterministic. It can be different in
> one list than in another - even if they contain the exact same items.
>
> Not yet sure how to work around this. We can probably try to sort it first,
> but then again, if they do not implement Comparable it won't help much. Or do
> a containsElement based on reflection as well - but that would be rather slow.
>
> Same with Maps. There is a good reason why the key at least should implement
> equals/hashCode. If this is not the case, then we are not able to implement
> this properly I fear.
>
> Any ideas?
>
> LieGrue,
> strub
>
> > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> >
> > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> >
> > For the diff, I'd suggest you test and iterable over a Collection
> > instead of a List.
> >
> > Then you'd need a separate test and traversal for Map instances.
> >
> > (Still no common super-interface in Java 21 for Collections and Maps...)
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> > wrote:
> >>
> >> Hi Gregory!
> >>
> >> I did try this out and figured that I didn't think it though. Maybe I need
> >> to go a few steps back and explain the problem:
> >>
> >> I have the following constellation
> >>
> >> public class SomeInnerDTO {int field..} // NOT implements equals!
> >> public class TheOuterDTO{ List innerList;..}
> >>
> >> My problem is that reflectionEquals (which I use in a unit test) tries to
> >> introspect fields even in java.util.classes. And for getting the values of
> >> those classes it tries to call a setAccessible(true);
> >> And obviously here it fails. There is a ticket already open [1] which
> >> sugggests to use trySetAccessible. But I fear that will still do nothing
> >> and you won't get access to those inner knowledge inside
> >> java.util.LinkedList etc.
> >>
> >> And using equals() on the List sadly won't help either, as the
> >> SomeInnerDTO would also get compared with equals(), but that will
> >> obviously use identity comparison only :(
> >>
> >>
> >> What I did for now (running all tests with a few projects right now, but
> >> looks promising):
> >>
> >> diff --git
> >> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> index ff5276b04..cf878da40 100644
> >> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object
> >> lhs, final Object rhs) {
> >> if (bypassReflectionClasses != null
> >> && (bypassReflectionClasses.contains(lhsClass) ||
> >> bypassReflectionClasses.contains(rhsClass))) {
> >> isEquals = lhs.equals(rhs);
> >> +} else if (testClass.isAssignableFrom(List.class)) {
> >> +List lList = (List) lhs;
> >> +List rList = (List) rhs;
> >> +if (lList.size() != rList.size()) {
> >> +isEquals = false;
> >> +return this;
> >> + }
> >> +for (int i = 0; i < lList.size(); i++) {
> >> +reflectionAppend(lList.get(i), rList.get(i));
> >> +}
> >> } else {
> >>
> >> I'm rather sure this is still not enough and there are plenty other cases
> >> to consider. Like e.g. handling Maps etc.
> >> But at least that's the direction I try to approach it right now. And of
> >> course this new part should potentially also be enabled by a flag...
> >>
> >> Will keep you updated.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/LANG-1711
> >>
> >>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> >>>
> >&
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
The question to me is how we can make it more robust.
In a Collection (but actually also in most lists) the order in which you get
the values (Iterator or get(i)) is not deterministic. It can be different in
one list than in another - even if they contain the exact same items.
Not yet sure how to work around this. We can probably try to sort it first, but
then again, if they do not implement Comparable it won't help much. Or do a
containsElement based on reflection as well - but that would be rather slow.
Same with Maps. There is a good reason why the key at least should implement
equals/hashCode. If this is not the case, then we are not able to implement
this properly I fear.
Any ideas?
LieGrue,
strub
> Am 06.03.2024 um 15:53 schrieb Gary Gregory :
>
> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
>
> For the diff, I'd suggest you test and iterable over a Collection
> instead of a List.
>
> Then you'd need a separate test and traversal for Map instances.
>
> (Still no common super-interface in Java 21 for Collections and Maps...)
>
> Gary
>
> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> wrote:
>>
>> Hi Gregory!
>>
>> I did try this out and figured that I didn't think it though. Maybe I need
>> to go a few steps back and explain the problem:
>>
>> I have the following constellation
>>
>> public class SomeInnerDTO {int field..} // NOT implements equals!
>> public class TheOuterDTO{ List innerList;..}
>>
>> My problem is that reflectionEquals (which I use in a unit test) tries to
>> introspect fields even in java.util.classes. And for getting the values of
>> those classes it tries to call a setAccessible(true);
>> And obviously here it fails. There is a ticket already open [1] which
>> sugggests to use trySetAccessible. But I fear that will still do nothing and
>> you won't get access to those inner knowledge inside java.util.LinkedList
>> etc.
>>
>> And using equals() on the List sadly won't help either, as the SomeInnerDTO
>> would also get compared with equals(), but that will obviously use identity
>> comparison only :(
>>
>>
>> What I did for now (running all tests with a few projects right now, but
>> looks promising):
>>
>> diff --git
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> index ff5276b04..cf878da40 100644
>> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs,
>> final Object rhs) {
>> if (bypassReflectionClasses != null
>> && (bypassReflectionClasses.contains(lhsClass) ||
>> bypassReflectionClasses.contains(rhsClass))) {
>> isEquals = lhs.equals(rhs);
>> +} else if (testClass.isAssignableFrom(List.class)) {
>> +List lList = (List) lhs;
>> +List rList = (List) rhs;
>> +if (lList.size() != rList.size()) {
>> +isEquals = false;
>> +return this;
>> +}
>> +for (int i = 0; i < lList.size(); i++) {
>> +reflectionAppend(lList.get(i), rList.get(i));
>> +}
>> } else {
>>
>> I'm rather sure this is still not enough and there are plenty other cases to
>> consider. Like e.g. handling Maps etc.
>> But at least that's the direction I try to approach it right now. And of
>> course this new part should potentially also be enabled by a flag...
>>
>> Will keep you updated.
>>
>> txs and LieGrue,
>> strub
>>
>>
>> [1] https://issues.apache.org/jira/browse/LANG-1711
>>
>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
>>>
>>> This sounds like a good idea to try. I would call the option something else
>>> though. We would not skip calling equals if it is defined right? How about
>>> "useEqualsIfPresent".
>>>
>>> Gary
>>>
>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
>>>> we get more and more nasty module problems. Mainly because the code tries
>>>> to recurse into java.util.* classes
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
Ah, right, custom "non-equalable" _inside_ Collections and Maps...
For the diff, I'd suggest you test and iterable over a Collection
instead of a List.
Then you'd need a separate test and traversal for Map instances.
(Still no common super-interface in Java 21 for Collections and Maps...)
Gary
On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg wrote:
>
> Hi Gregory!
>
> I did try this out and figured that I didn't think it though. Maybe I need to
> go a few steps back and explain the problem:
>
> I have the following constellation
>
> public class SomeInnerDTO {int field..} // NOT implements equals!
> public class TheOuterDTO{ List innerList;..}
>
> My problem is that reflectionEquals (which I use in a unit test) tries to
> introspect fields even in java.util.classes. And for getting the values of
> those classes it tries to call a setAccessible(true);
> And obviously here it fails. There is a ticket already open [1] which
> sugggests to use trySetAccessible. But I fear that will still do nothing and
> you won't get access to those inner knowledge inside java.util.LinkedList etc.
>
> And using equals() on the List sadly won't help either, as the SomeInnerDTO
> would also get compared with equals(), but that will obviously use identity
> comparison only :(
>
>
> What I did for now (running all tests with a few projects right now, but
> looks promising):
>
> diff --git
> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> index ff5276b04..cf878da40 100644
> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs,
> final Object rhs) {
> if (bypassReflectionClasses != null
> && (bypassReflectionClasses.contains(lhsClass) ||
> bypassReflectionClasses.contains(rhsClass))) {
> isEquals = lhs.equals(rhs);
> +} else if (testClass.isAssignableFrom(List.class)) {
> +List lList = (List) lhs;
> +List rList = (List) rhs;
> +if (lList.size() != rList.size()) {
> +isEquals = false;
> +return this;
> +}
> +for (int i = 0; i < lList.size(); i++) {
> +reflectionAppend(lList.get(i), rList.get(i));
> +}
> } else {
>
> I'm rather sure this is still not enough and there are plenty other cases to
> consider. Like e.g. handling Maps etc.
> But at least that's the direction I try to approach it right now. And of
> course this new part should potentially also be enabled by a flag...
>
> Will keep you updated.
>
> txs and LieGrue,
> strub
>
>
> [1] https://issues.apache.org/jira/browse/LANG-1711
>
> > Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> >
> > This sounds like a good idea to try. I would call the option something else
> > though. We would not skip calling equals if it is defined right? How about
> > "useEqualsIfPresent".
> >
> > Gary
> >
> > On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
> > wrote:
> >
> >> Hi!
> >>
> >> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
> >> we get more and more nasty module problems. Mainly because the code tries
> >> to recurse into java.util.* classes as well.
> >> I know that I can use setBypassReflectionClasses for those. But wouldn't
> >> it be fine to have an additional switch to 'skipOnCustomEquals' or similar?
> >>
> >> The idea is to only use reflection on classes which do not provide their
> >> own equals method. One can test this imo rather easily by checking whether
> >> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
> >> Object.class
> >> Do that for lhs and rhs and if both fit the criteria -> invoke equals
> >>
> >> Wdyt of that idea? Worth trying or is there already a better solution?
> >> With the new flag we can make sure that we do not change the current
> >> behaviour for existing use cases.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
Hi Gregory!
I did try this out and figured that I didn't think it though. Maybe I need to
go a few steps back and explain the problem:
I have the following constellation
public class SomeInnerDTO {int field..} // NOT implements equals!
public class TheOuterDTO{ List innerList;..}
My problem is that reflectionEquals (which I use in a unit test) tries to
introspect fields even in java.util.classes. And for getting the values of
those classes it tries to call a setAccessible(true);
And obviously here it fails. There is a ticket already open [1] which sugggests
to use trySetAccessible. But I fear that will still do nothing and you won't
get access to those inner knowledge inside java.util.LinkedList etc.
And using equals() on the List sadly won't help either, as the SomeInnerDTO
would also get compared with equals(), but that will obviously use identity
comparison only :(
What I did for now (running all tests with a few projects right now, but looks
promising):
diff --git a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
index ff5276b04..cf878da40 100644
--- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
+++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
@@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs,
final Object rhs) {
if (bypassReflectionClasses != null
&& (bypassReflectionClasses.contains(lhsClass) ||
bypassReflectionClasses.contains(rhsClass))) {
isEquals = lhs.equals(rhs);
+} else if (testClass.isAssignableFrom(List.class)) {
+List lList = (List) lhs;
+List rList = (List) rhs;
+if (lList.size() != rList.size()) {
+isEquals = false;
+return this;
+}
+for (int i = 0; i < lList.size(); i++) {
+reflectionAppend(lList.get(i), rList.get(i));
+}
} else {
I'm rather sure this is still not enough and there are plenty other cases to
consider. Like e.g. handling Maps etc.
But at least that's the direction I try to approach it right now. And of course
this new part should potentially also be enabled by a flag...
Will keep you updated.
txs and LieGrue,
strub
[1] https://issues.apache.org/jira/browse/LANG-1711
> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
>
> This sounds like a good idea to try. I would call the option something else
> though. We would not skip calling equals if it is defined right? How about
> "useEqualsIfPresent".
>
> Gary
>
> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
> wrote:
>
>> Hi!
>>
>> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
>> we get more and more nasty module problems. Mainly because the code tries
>> to recurse into java.util.* classes as well.
>> I know that I can use setBypassReflectionClasses for those. But wouldn't
>> it be fine to have an additional switch to 'skipOnCustomEquals' or similar?
>>
>> The idea is to only use reflection on classes which do not provide their
>> own equals method. One can test this imo rather easily by checking whether
>> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
>> Object.class
>> Do that for lhs and rhs and if both fit the criteria -> invoke equals
>>
>> Wdyt of that idea? Worth trying or is there already a better solution?
>> With the new flag we can make sure that we do not change the current
>> behaviour for existing use cases.
>>
>> LieGrue,
>> strub
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
This sounds like a good idea to try. I would call the option something else
though. We would not skip calling equals if it is defined right? How about
"useEqualsIfPresent".
Gary
On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
wrote:
> Hi!
>
> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
> we get more and more nasty module problems. Mainly because the code tries
> to recurse into java.util.* classes as well.
> I know that I can use setBypassReflectionClasses for those. But wouldn't
> it be fine to have an additional switch to 'skipOnCustomEquals' or similar?
>
> The idea is to only use reflection on classes which do not provide their
> own equals method. One can test this imo rather easily by checking whether
> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
> Object.class
> Do that for lhs and rhs and if both fit the criteria -> invoke equals
>
> Wdyt of that idea? Worth trying or is there already a better solution?
> With the new flag we can make sure that we do not change the current
> behaviour for existing use cases.
>
> LieGrue,
> strub
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
[LANG] EqualsBuilder#reflectionEquals feature brainstorming
Hi!
I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards we
get more and more nasty module problems. Mainly because the code tries to
recurse into java.util.* classes as well.
I know that I can use setBypassReflectionClasses for those. But wouldn't it be
fine to have an additional switch to 'skipOnCustomEquals' or similar?
The idea is to only use reflection on classes which do not provide their own
equals method. One can test this imo rather easily by checking whether
classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
Object.class
Do that for lhs and rhs and if both fit the criteria -> invoke equals
Wdyt of that idea? Worth trying or is there already a better solution?
With the new flag we can make sure that we do not change the current behaviour
for existing use cases.
LieGrue,
strub
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: java.desktop dependency in commons-lang
Hello Ethan, Feel free to provide a PR on GitHub but keep in mind that we cannot break binary compatibility within the 3.x release line. Gary On Tue, Mar 5, 2024, 11:45 AM Ethan McCue wrote: > Apologies if this has already been brought to your attention - i'm still a > bit unclear how to navigate the mailing lists. > > There is a dependency on the java.desktop module - i.e. Swing - in > commons-lang. It lives in AbstractCircuitBreaker here. > > > https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/concurrent/AbstractCircuitBreaker.java > > I don't know what exactly should be done, but making java.desktop a static > dependency would be nice. >
java.desktop dependency in commons-lang
Apologies if this has already been brought to your attention - i'm still a bit unclear how to navigate the mailing lists. There is a dependency on the java.desktop module - i.e. Swing - in commons-lang. It lives in AbstractCircuitBreaker here. https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/concurrent/AbstractCircuitBreaker.java I don't know what exactly should be done, but making java.desktop a static dependency would be nice.
Re: Apache Common Lang -- How do I compile or did I find a bug
Thank you so much for your help. I will have more questions tomorrow once I start working on the Jira Issue that I have selected On Tue, Dec 12, 2023 at 2:59 PM Gary Gregory wrote: > The simplest would to add a comment to the Jira ticket. > > Gary > > On Tue, Dec 12, 2023, 2:55 PM Charles Stockman > > wrote: > > > Thanks for your answers. What is the best practice for letting people > know > > you working an issue so they do not duplicate effort. > > > > On Tue, Dec 12, 2023 at 2:50 PM Gary Gregory > > wrote: > > > > > Hi Charles, > > > > > > Implementing (1) would cause an infinite loop of builds since the file > > thw > > > build would update is in the repo, and I don't think we want to play > > games > > > with not triggering builds when this or that file is changed. > > > > > > For (2), the file location is standard, so it feels a bit redundant. > The > > > Java requirement is in pom.xml. The Maven requirement is unspecified > > unless > > > the Maven enforcer plug in is configured. > > > > > > There is no hard process for assigning issues. I don't think non-Apache > > > folk can assign issues. You can ask to be assigned but it's not > sometimes > > > usually worth hassling with. > > > > > > Gary > > > > > > On Tue, Dec 12, 2023, 1:51 PM Charles Stockman < > > charlesstockm...@gmail.com > > > > > > > wrote: > > > > > > > Thank you very much for your help. I have updated to the latest > > version > > > of > > > > java 21 and it worked. > > > > > > > > For me, the best place to put the Build Information would be in the > > Build > > > > Section of the github pages since I would not expect that information > > to > > > be > > > > in a readme or POM file anymore. It has become a pseudo standard > that > > I > > > > would look on Github for instructions on building. > > > > > > > > Suggestions > > > > > > > >1. Is there some that we can dynamically update the GitHub Page so > > > that > > > >we can include the version of Java and Maven that the CI has used > > > >2. In the Github repo under the Build Instructions can we add a > link > > > to > > > >the file that the contains the build information and can it have > the > > > > title > > > >approximating the text "Maven and Java Version needed" > > > > > > > > I have selected a Jira Issue that I would enjoy working on. The > steps > > > > should be to create a Jira Account and then do I assign myself to the > > > issue > > > > or is there some process. > > > > > > > > Thanks for your help > > > > Charles Stockman. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 12, 2023 at 11:00 AM sebb wrote: > > > > > > > > > On Tue, 12 Dec 2023 at 14:21, Alex Herbert < > alex.d.herb...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory < > garydgreg...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > What's the best way to document this do you think? > > > > > > > > > > > > That lang is tested (and so should be built) with the latest JDK > of > > > > > > the respective stable release (8, 11, 17, 21)? > > > > > > > > > > > > This could live on the README in the GH repo. This would require > an > > > > > > update to the commons-build-plugin that generates it. > > > > > > > > > > The build plugin includes the POM description text, so it can be > > added > > > > > there. > > > > > > > > > > > But for a start > > > > > > we can add a few sentences to the lang README under the building > > > > > > section: > > > > > > > > > > > > "The code is tested using the latest revision of the JDK for > > > supported > > > > > > LTS releases. Please ensure your build environment is up-to-date > > and > > > > > > kindly report any build issues." > > > > > > > > > > > > This should provide a first indicator to a user that the JDK must > > be > > > > > > up-to-date and welcomes any feedback on building. This text may > not > > > be > > > > > > suitable for all repos if they do not test across all LTS > versions > > of > > > > > > the JDK so may need some revision for the build-plugin. > > > > > > > > > > > > Alex > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > >
Re: Apache Common Lang -- How do I compile or did I find a bug
The simplest would to add a comment to the Jira ticket. Gary On Tue, Dec 12, 2023, 2:55 PM Charles Stockman wrote: > Thanks for your answers. What is the best practice for letting people know > you working an issue so they do not duplicate effort. > > On Tue, Dec 12, 2023 at 2:50 PM Gary Gregory > wrote: > > > Hi Charles, > > > > Implementing (1) would cause an infinite loop of builds since the file > thw > > build would update is in the repo, and I don't think we want to play > games > > with not triggering builds when this or that file is changed. > > > > For (2), the file location is standard, so it feels a bit redundant. The > > Java requirement is in pom.xml. The Maven requirement is unspecified > unless > > the Maven enforcer plug in is configured. > > > > There is no hard process for assigning issues. I don't think non-Apache > > folk can assign issues. You can ask to be assigned but it's not sometimes > > usually worth hassling with. > > > > Gary > > > > On Tue, Dec 12, 2023, 1:51 PM Charles Stockman < > charlesstockm...@gmail.com > > > > > wrote: > > > > > Thank you very much for your help. I have updated to the latest > version > > of > > > java 21 and it worked. > > > > > > For me, the best place to put the Build Information would be in the > Build > > > Section of the github pages since I would not expect that information > to > > be > > > in a readme or POM file anymore. It has become a pseudo standard that > I > > > would look on Github for instructions on building. > > > > > > Suggestions > > > > > >1. Is there some that we can dynamically update the GitHub Page so > > that > > >we can include the version of Java and Maven that the CI has used > > >2. In the Github repo under the Build Instructions can we add a link > > to > > >the file that the contains the build information and can it have the > > > title > > >approximating the text "Maven and Java Version needed" > > > > > > I have selected a Jira Issue that I would enjoy working on. The steps > > > should be to create a Jira Account and then do I assign myself to the > > issue > > > or is there some process. > > > > > > Thanks for your help > > > Charles Stockman. > > > > > > > > > > > > > > > > > > On Tue, Dec 12, 2023 at 11:00 AM sebb wrote: > > > > > > > On Tue, 12 Dec 2023 at 14:21, Alex Herbert > > > > > wrote: > > > > > > > > > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory > > > > > wrote: > > > > > > > > > > > > What's the best way to document this do you think? > > > > > > > > > > That lang is tested (and so should be built) with the latest JDK of > > > > > the respective stable release (8, 11, 17, 21)? > > > > > > > > > > This could live on the README in the GH repo. This would require an > > > > > update to the commons-build-plugin that generates it. > > > > > > > > The build plugin includes the POM description text, so it can be > added > > > > there. > > > > > > > > > But for a start > > > > > we can add a few sentences to the lang README under the building > > > > > section: > > > > > > > > > > "The code is tested using the latest revision of the JDK for > > supported > > > > > LTS releases. Please ensure your build environment is up-to-date > and > > > > > kindly report any build issues." > > > > > > > > > > This should provide a first indicator to a user that the JDK must > be > > > > > up-to-date and welcomes any feedback on building. This text may not > > be > > > > > suitable for all repos if they do not test across all LTS versions > of > > > > > the JDK so may need some revision for the build-plugin. > > > > > > > > > > Alex > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > >
Re: Apache Common Lang -- How do I compile or did I find a bug
Thanks for your answers. What is the best practice for letting people know you working an issue so they do not duplicate effort. On Tue, Dec 12, 2023 at 2:50 PM Gary Gregory wrote: > Hi Charles, > > Implementing (1) would cause an infinite loop of builds since the file thw > build would update is in the repo, and I don't think we want to play games > with not triggering builds when this or that file is changed. > > For (2), the file location is standard, so it feels a bit redundant. The > Java requirement is in pom.xml. The Maven requirement is unspecified unless > the Maven enforcer plug in is configured. > > There is no hard process for assigning issues. I don't think non-Apache > folk can assign issues. You can ask to be assigned but it's not sometimes > usually worth hassling with. > > Gary > > On Tue, Dec 12, 2023, 1:51 PM Charles Stockman > > wrote: > > > Thank you very much for your help. I have updated to the latest version > of > > java 21 and it worked. > > > > For me, the best place to put the Build Information would be in the Build > > Section of the github pages since I would not expect that information to > be > > in a readme or POM file anymore. It has become a pseudo standard that I > > would look on Github for instructions on building. > > > > Suggestions > > > >1. Is there some that we can dynamically update the GitHub Page so > that > >we can include the version of Java and Maven that the CI has used > >2. In the Github repo under the Build Instructions can we add a link > to > >the file that the contains the build information and can it have the > > title > >approximating the text "Maven and Java Version needed" > > > > I have selected a Jira Issue that I would enjoy working on. The steps > > should be to create a Jira Account and then do I assign myself to the > issue > > or is there some process. > > > > Thanks for your help > > Charles Stockman. > > > > > > > > > > > > On Tue, Dec 12, 2023 at 11:00 AM sebb wrote: > > > > > On Tue, 12 Dec 2023 at 14:21, Alex Herbert > > > wrote: > > > > > > > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory > > > wrote: > > > > > > > > > > What's the best way to document this do you think? > > > > > > > > That lang is tested (and so should be built) with the latest JDK of > > > > the respective stable release (8, 11, 17, 21)? > > > > > > > > This could live on the README in the GH repo. This would require an > > > > update to the commons-build-plugin that generates it. > > > > > > The build plugin includes the POM description text, so it can be added > > > there. > > > > > > > But for a start > > > > we can add a few sentences to the lang README under the building > > > > section: > > > > > > > > "The code is tested using the latest revision of the JDK for > supported > > > > LTS releases. Please ensure your build environment is up-to-date and > > > > kindly report any build issues." > > > > > > > > This should provide a first indicator to a user that the JDK must be > > > > up-to-date and welcomes any feedback on building. This text may not > be > > > > suitable for all repos if they do not test across all LTS versions of > > > > the JDK so may need some revision for the build-plugin. > > > > > > > > Alex > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Re: Apache Common Lang -- How do I compile or did I find a bug
Hi Charles, Implementing (1) would cause an infinite loop of builds since the file thw build would update is in the repo, and I don't think we want to play games with not triggering builds when this or that file is changed. For (2), the file location is standard, so it feels a bit redundant. The Java requirement is in pom.xml. The Maven requirement is unspecified unless the Maven enforcer plug in is configured. There is no hard process for assigning issues. I don't think non-Apache folk can assign issues. You can ask to be assigned but it's not sometimes usually worth hassling with. Gary On Tue, Dec 12, 2023, 1:51 PM Charles Stockman wrote: > Thank you very much for your help. I have updated to the latest version of > java 21 and it worked. > > For me, the best place to put the Build Information would be in the Build > Section of the github pages since I would not expect that information to be > in a readme or POM file anymore. It has become a pseudo standard that I > would look on Github for instructions on building. > > Suggestions > >1. Is there some that we can dynamically update the GitHub Page so that >we can include the version of Java and Maven that the CI has used >2. In the Github repo under the Build Instructions can we add a link to >the file that the contains the build information and can it have the > title >approximating the text "Maven and Java Version needed" > > I have selected a Jira Issue that I would enjoy working on. The steps > should be to create a Jira Account and then do I assign myself to the issue > or is there some process. > > Thanks for your help > Charles Stockman. > > > > > > On Tue, Dec 12, 2023 at 11:00 AM sebb wrote: > > > On Tue, 12 Dec 2023 at 14:21, Alex Herbert > > wrote: > > > > > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory > > wrote: > > > > > > > > What's the best way to document this do you think? > > > > > > That lang is tested (and so should be built) with the latest JDK of > > > the respective stable release (8, 11, 17, 21)? > > > > > > This could live on the README in the GH repo. This would require an > > > update to the commons-build-plugin that generates it. > > > > The build plugin includes the POM description text, so it can be added > > there. > > > > > But for a start > > > we can add a few sentences to the lang README under the building > > > section: > > > > > > "The code is tested using the latest revision of the JDK for supported > > > LTS releases. Please ensure your build environment is up-to-date and > > > kindly report any build issues." > > > > > > This should provide a first indicator to a user that the JDK must be > > > up-to-date and welcomes any feedback on building. This text may not be > > > suitable for all repos if they do not test across all LTS versions of > > > the JDK so may need some revision for the build-plugin. > > > > > > Alex > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: Apache Common Lang -- How do I compile or did I find a bug
Thank you very much for your help. I have updated to the latest version of java 21 and it worked. For me, the best place to put the Build Information would be in the Build Section of the github pages since I would not expect that information to be in a readme or POM file anymore. It has become a pseudo standard that I would look on Github for instructions on building. Suggestions 1. Is there some that we can dynamically update the GitHub Page so that we can include the version of Java and Maven that the CI has used 2. In the Github repo under the Build Instructions can we add a link to the file that the contains the build information and can it have the title approximating the text "Maven and Java Version needed" I have selected a Jira Issue that I would enjoy working on. The steps should be to create a Jira Account and then do I assign myself to the issue or is there some process. Thanks for your help Charles Stockman. On Tue, Dec 12, 2023 at 11:00 AM sebb wrote: > On Tue, 12 Dec 2023 at 14:21, Alex Herbert > wrote: > > > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory > wrote: > > > > > > What's the best way to document this do you think? > > > > That lang is tested (and so should be built) with the latest JDK of > > the respective stable release (8, 11, 17, 21)? > > > > This could live on the README in the GH repo. This would require an > > update to the commons-build-plugin that generates it. > > The build plugin includes the POM description text, so it can be added > there. > > > But for a start > > we can add a few sentences to the lang README under the building > > section: > > > > "The code is tested using the latest revision of the JDK for supported > > LTS releases. Please ensure your build environment is up-to-date and > > kindly report any build issues." > > > > This should provide a first indicator to a user that the JDK must be > > up-to-date and welcomes any feedback on building. This text may not be > > suitable for all repos if they do not test across all LTS versions of > > the JDK so may need some revision for the build-plugin. > > > > Alex > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: Apache Common Lang -- How do I compile or did I find a bug
On Tue, 12 Dec 2023 at 14:21, Alex Herbert wrote: > > On Tue, 12 Dec 2023 at 13:20, Gary Gregory wrote: > > > > What's the best way to document this do you think? > > That lang is tested (and so should be built) with the latest JDK of > the respective stable release (8, 11, 17, 21)? > > This could live on the README in the GH repo. This would require an > update to the commons-build-plugin that generates it. The build plugin includes the POM description text, so it can be added there. > But for a start > we can add a few sentences to the lang README under the building > section: > > "The code is tested using the latest revision of the JDK for supported > LTS releases. Please ensure your build environment is up-to-date and > kindly report any build issues." > > This should provide a first indicator to a user that the JDK must be > up-to-date and welcomes any feedback on building. This text may not be > suitable for all repos if they do not test across all LTS versions of > the JDK so may need some revision for the build-plugin. > > Alex > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Common Lang -- How do I compile or did I find a bug
On Tue, 12 Dec 2023 at 13:20, Gary Gregory wrote: > > What's the best way to document this do you think? That lang is tested (and so should be built) with the latest JDK of the respective stable release (8, 11, 17, 21)? This could live on the README in the GH repo. This would require an update to the commons-build-plugin that generates it. But for a start we can add a few sentences to the lang README under the building section: "The code is tested using the latest revision of the JDK for supported LTS releases. Please ensure your build environment is up-to-date and kindly report any build issues." This should provide a first indicator to a user that the JDK must be up-to-date and welcomes any feedback on building. This text may not be suitable for all repos if they do not test across all LTS versions of the JDK so may need some revision for the build-plugin. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Common Lang -- How do I compile or did I find a bug
What's the best way to document this do you think? Gary On Tue, Dec 12, 2023, 7:19 AM Alex Herbert wrote: > I updated JDK 17.0.6 to 17.0.9 and lang now builds on my mac: > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > Java version: 17.0.9, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > So this is a JDK issue. > > Alex > > On Tue, 12 Dec 2023 at 11:51, Gary Gregory wrote: > > > > See the GutHub builds as well. Make sure you have the latest Java version > > of the major release line you are using, which is not the case here, and > > might not matter. > > > > Note that some of the tests make allowances for bugs in the JDK date > > classes. > > > > Gary > > > > On Tue, Dec 12, 2023, 6:18 AM Alex Herbert > wrote: > > > > > I can confirm I see 3 test failures in the FastDateParser using: > > > > > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > > > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > > > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > > > Default locale: en_GB, platform encoding: UTF-8 > > > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > > > > > --- > > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > > > java.text.ParseException: Unparseable date: Tempo universale > > > coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo > > > universale coordinato', parser = 'FastDateParser[z, it, GMT]' > > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > > > java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko, > > > zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko, > > > GMT]' > > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172 > > > java.text.ParseException: Unparseable date: normaltid – Kanton: with > > > locale = nb, id = 'Pacific/Kanton', timeZone = > > > > > > > sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null] > > > ... > > > --- > > > > > > Build is fine using on MacOS using: > > > > > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > > > Java version: 11.0.18, vendor: Eclipse Adoptium, runtime: > > > /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home > > > Default locale: en_GB, platform encoding: UTF-8 > > > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > > > > > Build is fine on Linux JDK 17 using: > > > > > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > > > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime: > > > /usr/lib/jvm/jdk-17.0.4.1 > > > Default locale: en_GB, platform encoding: UTF-8 > > > OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: > > > "unix" > > > > > > The GH actions builds are green for MacOS latest on all JDKs. I see > > > you are using a similar OS version to my mac. So this may be a MacOS > > > Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else > > > can replicate it on MacOS. > > > > > > Alex > > > > > > On Tue, 12 Dec 2023 at 08:52, Charles Stockman > > > wrote: > > > > > > > > Hello and thanks for your help. > > > > > > > > > > > > How do I compile or did I find a bug ? > > > > > > > > > > > > I have been been attempting to build the latest version of Apache > > > > > > > > Common-Lang. > > > > > > > > > > > > The GitHub repository that I have used is > > > > > > > > https://github.com/apache/commons-lang.git > > > &g
Re: Apache Common Lang -- How do I compile or did I find a bug
I updated JDK 17.0.6 to 17.0.9 and lang now builds on my mac: Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Java version: 17.0.9, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" So this is a JDK issue. Alex On Tue, 12 Dec 2023 at 11:51, Gary Gregory wrote: > > See the GutHub builds as well. Make sure you have the latest Java version > of the major release line you are using, which is not the case here, and > might not matter. > > Note that some of the tests make allowances for bugs in the JDK date > classes. > > Gary > > On Tue, Dec 12, 2023, 6:18 AM Alex Herbert wrote: > > > I can confirm I see 3 test failures in the FastDateParser using: > > > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > > Default locale: en_GB, platform encoding: UTF-8 > > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > > > --- > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > > java.text.ParseException: Unparseable date: Tempo universale > > coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo > > universale coordinato', parser = 'FastDateParser[z, it, GMT]' > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > > java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko, > > zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko, > > GMT]' > > [ERROR] > > > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172 > > java.text.ParseException: Unparseable date: normaltid – Kanton: with > > locale = nb, id = 'Pacific/Kanton', timeZone = > > > > sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null] > > ... > > --- > > > > Build is fine using on MacOS using: > > > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > > Java version: 11.0.18, vendor: Eclipse Adoptium, runtime: > > /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home > > Default locale: en_GB, platform encoding: UTF-8 > > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > > > Build is fine on Linux JDK 17 using: > > > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime: > > /usr/lib/jvm/jdk-17.0.4.1 > > Default locale: en_GB, platform encoding: UTF-8 > > OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: > > "unix" > > > > The GH actions builds are green for MacOS latest on all JDKs. I see > > you are using a similar OS version to my mac. So this may be a MacOS > > Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else > > can replicate it on MacOS. > > > > Alex > > > > On Tue, 12 Dec 2023 at 08:52, Charles Stockman > > wrote: > > > > > > Hello and thanks for your help. > > > > > > > > > How do I compile or did I find a bug ? > > > > > > > > > I have been been attempting to build the latest version of Apache > > > > > > Common-Lang. > > > > > > > > > The GitHub repository that I have used is > > > > > > https://github.com/apache/commons-lang.git > > > > > > > > > I have the billed instructions mentioned in the following section : > > > > > > https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building > > > > > > > > > The maven and java version that I have used is: > > > > > > > > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > > > > > > Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec > > > > > > Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: = > >
Re: Apache Common Lang -- How do I compile or did I find a bug
See the GutHub builds as well. Make sure you have the latest Java version of the major release line you are using, which is not the case here, and might not matter. Note that some of the tests make allowances for bugs in the JDK date classes. Gary On Tue, Dec 12, 2023, 6:18 AM Alex Herbert wrote: > I can confirm I see 3 test failures in the FastDateParser using: > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > --- > [ERROR] > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > java.text.ParseException: Unparseable date: Tempo universale > coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo > universale coordinato', parser = 'FastDateParser[z, it, GMT]' > [ERROR] > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 > java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko, > zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko, > GMT]' > [ERROR] > > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172 > java.text.ParseException: Unparseable date: normaltid – Kanton: with > locale = nb, id = 'Pacific/Kanton', timeZone = > > sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null] > ... > --- > > Build is fine using on MacOS using: > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > Java version: 11.0.18, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" > > Build is fine on Linux JDK 17 using: > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime: > /usr/lib/jvm/jdk-17.0.4.1 > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: > "unix" > > The GH actions builds are green for MacOS latest on all JDKs. I see > you are using a similar OS version to my mac. So this may be a MacOS > Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else > can replicate it on MacOS. > > Alex > > On Tue, 12 Dec 2023 at 08:52, Charles Stockman > wrote: > > > > Hello and thanks for your help. > > > > > > How do I compile or did I find a bug ? > > > > > > I have been been attempting to build the latest version of Apache > > > > Common-Lang. > > > > > > The GitHub repository that I have used is > > > > https://github.com/apache/commons-lang.git > > > > > > I have the billed instructions mentioned in the following section : > > > > https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building > > > > > > The maven and java version that I have used is: > > > > > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > > > > Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec > > > > Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: = > > > > /Users/charlesstockman/.sdkman/candidates/java/17.0.7-tem > > > > Default locale: en_US, platform encoding: UTF-8 > > > > OS name: "mac os x", version: "13.4", arch: "aarch64", family: = > > > > "mac" > > > > > > The steps were > > > > > > 1. git clone https://github.com/apache/commons-lang.git > > > > 1. cd commons-lang > > > > 2. mvn > > > > > > I have received the following error and attached the output > > > > > > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.2.2:test (default-test) on > project commons-lang3: There are test failures. > > > > [ERROR] > > > > [ERROR] Please refer to > /Users/charlesstockman/otherGit/commons-lang/target/surefire-reports for > the individual test results. > > >
Re: Apache Common Lang -- How do I compile or did I find a bug
I can confirm I see 3 test failures in the FastDateParser using: Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" --- [ERROR] FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 java.text.ParseException: Unparseable date: Tempo universale coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo universale coordinato', parser = 'FastDateParser[z, it, GMT]' [ERROR] FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147 java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko, zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko, GMT]' [ERROR] FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172 java.text.ParseException: Unparseable date: normaltid – Kanton: with locale = nb, id = 'Pacific/Kanton', timeZone = sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null] ... --- Build is fine using on MacOS using: Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Java version: 11.0.18, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac" Build is fine on Linux JDK 17 using: Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Java version: 17.0.4.1, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-17.0.4.1 Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: "unix" The GH actions builds are green for MacOS latest on all JDKs. I see you are using a similar OS version to my mac. So this may be a MacOS Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else can replicate it on MacOS. Alex On Tue, 12 Dec 2023 at 08:52, Charles Stockman wrote: > > Hello and thanks for your help. > > > How do I compile or did I find a bug ? > > > I have been been attempting to build the latest version of Apache > > Common-Lang. > > > The GitHub repository that I have used is > > https://github.com/apache/commons-lang.git > > > I have the billed instructions mentioned in the following section : > > https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building > > > The maven and java version that I have used is: > > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > > Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec > > Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: = > > /Users/charlesstockman/.sdkman/candidates/java/17.0.7-tem > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "13.4", arch: "aarch64", family: = > > "mac" > > > The steps were > > > 1. git clone https://github.com/apache/commons-lang.git > > 1. cd commons-lang > > 2. mvn > > > I have received the following error and attached the output > > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.2.2:test (default-test) on > project commons-lang3: There are test failures. > > [ERROR] > > [ERROR] Please refer to > /Users/charlesstockman/otherGit/commons-lang/target/surefire-reports for the > individual test results. > > [ERROR] Please refer to dump files (if any exist) [date].dump, > [date]-jvmRun[N].dump and [date].dumpstream. > > [ERROR] -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > charlesstockman@Charless-Mini commons-lang % > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Apache Common Lang -- How do I compile or did I find a bug
Hello and thanks for your help. How do I compile or did I find a bug ? I have been been attempting to build the latest version of Apache Common-Lang. The GitHub repository that I have used is https://github.com/apache/commons-lang.git I have the billed instructions mentioned in the following section : https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building The maven and java version that I have used is: Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: = /Users/charlesstockman/.sdkman/candidates/java/17.0.7-tem Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.4", arch: "aarch64", family: = "mac" The steps were 1. git clone https://github.com/apache/commons-lang.git 1. cd commons-lang 2. mvn I have received the following error and attached the output [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.2.2:test (default-test) on project commons-lang3: There are test failures. [ERROR] [ERROR] Please refer to /Users/charlesstockman/otherGit/commons-lang/target/surefire-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException charlesstockman@Charless-Mini commons-lang % <>
[ANNOUNCE] Apache Commons Lang Version 3.14.0
The Apache Commons team is pleased to announce Apache Commons Lang Version 3.14.0. Commons Lang is a set of utility functions and reusable components that should be of use in any Java environment. Starting with Commons Lang 3.9, we target Java 8, making use of those features. For advice on upgrading from 2.x to 3.x, see: https://commons.apache.org/lang/article3_0.html Apache Commons Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in java.lang. New features and bug fixes (Java 8 or above). Historical list of changes: https://commons.apache.org/proper/commons-lang/changes-report.html For complete information on Apache Commons Lang, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Lang website: https://commons.apache.org/proper/commons-lang/ Download page: https://commons.apache.org/proper/commons-lang/download_lang.cgi Have fun! Gary Gregory - Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Bad download links in the Download web page (3.13.0)
TY Cpm: Fixed! Yes, this is the right place :-) Gary On Sun, Nov 26, 2023 at 9:38 PM Christian P. MOMON wrote: > > > Hi, > > In the web page "Download Apache Commons Lang" > (https://commons.apache.org/proper/commons-lang/download_lang.cgi), in > the section "Apache Commons Lang 3.13.0", the four download links give > "404 Not Found error": > > - commons-lang3-3.13.0-bin.tar.gz > - commons-lang3-3.13.0-bin.zip > - commons-lang3-3.13.0-src.tar.gz > - commons-lang3-3.13.0-src.zip > > Example: > > # curl -I > https://dlcdn.apache.org//commons/lang/binaries/commons-lang3-3.13.0-bin.tar.gz > > HTTP/2 404 > > SHA512sum and PGP links are good. > > Request: make download links operational. > > Questions: > - Where to share the issue? > - Is this mailing list the right place? > - Or an issue in the LANG Jira project? > - Or in the "www.apache.org website" project (ASFSITE)? > > Thank you in advance :-) > > Regards, > Cpm. > -- > DEVINSY sarl - Développements en S.I. > http://www.devinsy.fr/ > Tél. +33 (0)6 26 72 40 04 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LANG] Bad download links in the Download web page (3.13.0)
Hi, In the web page "Download Apache Commons Lang" (https://commons.apache.org/proper/commons-lang/download_lang.cgi), in the section "Apache Commons Lang 3.13.0", the four download links give "404 Not Found error": - commons-lang3-3.13.0-bin.tar.gz - commons-lang3-3.13.0-bin.zip - commons-lang3-3.13.0-src.tar.gz - commons-lang3-3.13.0-src.zip Example: # curl -I https://dlcdn.apache.org//commons/lang/binaries/commons-lang3-3.13.0-bin.tar.gz HTTP/2 404 SHA512sum and PGP links are good. Request: make download links operational. Questions: - Where to share the issue? - Is this mailing list the right place? - Or an issue in the LANG Jira project? - Or in the "www.apache.org website" project (ASFSITE)? Thank you in advance :-) Regards, Cpm. -- DEVINSY sarl - Développements en S.I. http://www.devinsy.fr/ Tél. +33 (0)6 26 72 40 04 OpenPGP_signature.asc Description: OpenPGP digital signature
[RESULT][VOTE] Release Apache Commons Lang 3.14.0 based on RC1
This vote thread passes with the following +1 binding votes: - Bruno Kinoshita - Rob Tompkins - Gary Gregory Gary On Tue, Nov 21, 2023 at 8:29 PM Gary Gregory wrote: > > My +1 > > Gary > > On Sun, Nov 19, 2023 at 11:05 AM Rob Tompkins wrote: > > > > Looking over the release there are some japicmp curiosities that I think > > are k, and the CPD report has a few nits in it. > > Otherwise all looks good. > > > > +1 > > > > -Rob > > > > Thank you for the good work!!! > > > > > On Nov 18, 2023, at 10:15 AM, Gary Gregory wrote: > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons Lang 3.13.0 was released, so I would like to release Apache > > > Commons Lang 3.14.0. > > > > > > Apache Commons Lang 3.14.0 RC1 is available for review here: > > >https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1 > > > (svn revision 65412) > > > > > > The Git tag commons-lang-3.14.0-RC1 commit for this RC is > > > c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 which you can browse here: > > > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 > > > You may checkout this tag using: > > >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > > > --branch commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1 > > > > > > Maven artifacts are here: > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1674/org/apache/commons/commons-lang3/3.14.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Sat Nov 18 10:03:24 EST 2023 > > > Apache\ Commons\ > > > Lang-3.14.0.spdx.rdf.xml=497cb8e231b7c3421f4ed27063f889c1ff9815d5cc76aa992d7c1f166ffe0ced0313e3a8daf17d0f2eb412ee4ce8923fb87b7abd6e897a6180005d9ce2c97b15 > > > commons-lang3-3.14.0-bin.tar.gz=8e7e62418a49ba810512c13a640a8bf35f878fcd54af32fdaabe37817f58b21b475980ba663fba4887e45ef8d88af8ff17796f20d202e929e8e2574546dc > > > commons-lang3-3.14.0-bin.zip=444ef65dfe130fdb50450778c757a23ccb16fdf4ac7afe655934ae5b0d3faf7b2001ba951383d9e69baeb1fdc879c81e4542f8ceb47c7044fb5266cdddbc0db6 > > > commons-lang3-3.14.0-bom.json=cce914a85f156c5757df5e6c28b9964f0be04f92035557491dd37dbef28efa812c4e975c391c38e2bfe807a530585ab666e40b544f76cc7ad9fb8a04c6012fbd > > > commons-lang3-3.14.0-bom.xml=51a55d0d1bcd2f093cb2f0b84870b2381ab9da740582cba04ae02ea6e50a97e0656bd2bc2871a8d6a7fc313f033ab70544134845dec193552ef9ecc8db3a0ecb > > > commons-lang3-3.14.0-javadoc.jar=40b1d2b1fe6a621d715d1290096942107f1d1bbb41a51096c70292be0803d5a6f9214fd8b5810ad154848d20bb498871ae9d2f8ad11649f0affaaa00f7c8e25c > > > commons-lang3-3.14.0-sources.jar=16363e06b52908ecbec9a62f4b1e0a39cf3de9c646504f0cee5bbe845739cbfb99f01438808bab2c407fc72d4adf212487886422415d9972614c5ee96273deab > > > commons-lang3-3.14.0-src.tar.gz=1ee4176c3588c11594a79f416a1f34b063cddb10c2124a37640fee48e5d8135091573002b6bf1eda5a60a324c1125665dadc93f9bfda32c9270c35113b6e1bea > > > commons-lang3-3.14.0-src.zip=8c1cc37e2be29e71cfb80775c4887b2c6cd466ef05bb59a4afc11bc5fbe9b253dc57bda5e29b05ca6f1e9b497d84c56a5573c1e64b659a43bedcbe5bc3105b11 > > > commons-lang3-3.14.0-test-sources.jar=dd8d9670cf91b4504804f855c74c75109060c86e87eeb5c56f31ff9241ffde272855fac21ce456303dac1578e5c58238cb59e0e628854ae9d4f1451e15f969b8 > > > commons-lang3-3.14.0-tests.jar=e5cc518ba310db0a20361502a0bb8896f05f0c0552b8170a37485922030e15a1221e9e027753ad522202af2326664cb2f0c14d409bac6bfe44b9065fc07bbc02 > > > > > > I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P > > > japicmp clean package site deploy' > > > > > > using: > > > > > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > > > Maven home: /usr/local/Cellar/maven/3.9.5/libexec > > > Java version: 21.0.1, vendor: Homebrew, runtime: > > > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home > > > Default locale: en_US, platform encoding: UTF-8 > > > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac" > > > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct > > > 9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64 > > > > > > Details of changes since 3.13.0 are in the release notes: > > > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/RELEASE-NOTES.txt > > > > >
Re: [VOTE] Release Apache Commons Lang 3.14.0 based on RC1
My +1 Gary On Sun, Nov 19, 2023 at 11:05 AM Rob Tompkins wrote: > > Looking over the release there are some japicmp curiosities that I think are > k, and the CPD report has a few nits in it. > Otherwise all looks good. > > +1 > > -Rob > > Thank you for the good work!!! > > > On Nov 18, 2023, at 10:15 AM, Gary Gregory wrote: > > > > We have fixed a few bugs and added some enhancements since Apache > > Commons Lang 3.13.0 was released, so I would like to release Apache > > Commons Lang 3.14.0. > > > > Apache Commons Lang 3.14.0 RC1 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1 > > (svn revision 65412) > > > > The Git tag commons-lang-3.14.0-RC1 commit for this RC is > > c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 > > You may checkout this tag using: > >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > > --branch commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1674/org/apache/commons/commons-lang3/3.14.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Sat Nov 18 10:03:24 EST 2023 > > Apache\ Commons\ > > Lang-3.14.0.spdx.rdf.xml=497cb8e231b7c3421f4ed27063f889c1ff9815d5cc76aa992d7c1f166ffe0ced0313e3a8daf17d0f2eb412ee4ce8923fb87b7abd6e897a6180005d9ce2c97b15 > > commons-lang3-3.14.0-bin.tar.gz=8e7e62418a49ba810512c13a640a8bf35f878fcd54af32fdaabe37817f58b21b475980ba663fba4887e45ef8d88af8ff17796f20d202e929e8e2574546dc > > commons-lang3-3.14.0-bin.zip=444ef65dfe130fdb50450778c757a23ccb16fdf4ac7afe655934ae5b0d3faf7b2001ba951383d9e69baeb1fdc879c81e4542f8ceb47c7044fb5266cdddbc0db6 > > commons-lang3-3.14.0-bom.json=cce914a85f156c5757df5e6c28b9964f0be04f92035557491dd37dbef28efa812c4e975c391c38e2bfe807a530585ab666e40b544f76cc7ad9fb8a04c6012fbd > > commons-lang3-3.14.0-bom.xml=51a55d0d1bcd2f093cb2f0b84870b2381ab9da740582cba04ae02ea6e50a97e0656bd2bc2871a8d6a7fc313f033ab70544134845dec193552ef9ecc8db3a0ecb > > commons-lang3-3.14.0-javadoc.jar=40b1d2b1fe6a621d715d1290096942107f1d1bbb41a51096c70292be0803d5a6f9214fd8b5810ad154848d20bb498871ae9d2f8ad11649f0affaaa00f7c8e25c > > commons-lang3-3.14.0-sources.jar=16363e06b52908ecbec9a62f4b1e0a39cf3de9c646504f0cee5bbe845739cbfb99f01438808bab2c407fc72d4adf212487886422415d9972614c5ee96273deab > > commons-lang3-3.14.0-src.tar.gz=1ee4176c3588c11594a79f416a1f34b063cddb10c2124a37640fee48e5d8135091573002b6bf1eda5a60a324c1125665dadc93f9bfda32c9270c35113b6e1bea > > commons-lang3-3.14.0-src.zip=8c1cc37e2be29e71cfb80775c4887b2c6cd466ef05bb59a4afc11bc5fbe9b253dc57bda5e29b05ca6f1e9b497d84c56a5573c1e64b659a43bedcbe5bc3105b11 > > commons-lang3-3.14.0-test-sources.jar=dd8d9670cf91b4504804f855c74c75109060c86e87eeb5c56f31ff9241ffde272855fac21ce456303dac1578e5c58238cb59e0e628854ae9d4f1451e15f969b8 > > commons-lang3-3.14.0-tests.jar=e5cc518ba310db0a20361502a0bb8896f05f0c0552b8170a37485922030e15a1221e9e027753ad522202af2326664cb2f0c14d409bac6bfe44b9065fc07bbc02 > > > > I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P > > japicmp clean package site deploy' > > > > using: > > > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > > Maven home: /usr/local/Cellar/maven/3.9.5/libexec > > Java version: 21.0.1, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac" > > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct > > 9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.13.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/index.html > >(note some *relative* links are broken and the 3.14.0 directories > > are not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.13.0): > > > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/japicmp.html > > > >
Re: [VOTE] Release Apache Commons Lang 3.14.0 based on RC1
Looking over the release there are some japicmp curiosities that I think are k, and the CPD report has a few nits in it. Otherwise all looks good. +1 -Rob Thank you for the good work!!! > On Nov 18, 2023, at 10:15 AM, Gary Gregory wrote: > > We have fixed a few bugs and added some enhancements since Apache > Commons Lang 3.13.0 was released, so I would like to release Apache > Commons Lang 3.14.0. > > Apache Commons Lang 3.14.0 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1 > (svn revision 65412) > > The Git tag commons-lang-3.14.0-RC1 commit for this RC is > c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1674/org/apache/commons/commons-lang3/3.14.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Nov 18 10:03:24 EST 2023 > Apache\ Commons\ > Lang-3.14.0.spdx.rdf.xml=497cb8e231b7c3421f4ed27063f889c1ff9815d5cc76aa992d7c1f166ffe0ced0313e3a8daf17d0f2eb412ee4ce8923fb87b7abd6e897a6180005d9ce2c97b15 > commons-lang3-3.14.0-bin.tar.gz=8e7e62418a49ba810512c13a640a8bf35f878fcd54af32fdaabe37817f58b21b475980ba663fba4887e45ef8d88af8ff17796f20d202e929e8e2574546dc > commons-lang3-3.14.0-bin.zip=444ef65dfe130fdb50450778c757a23ccb16fdf4ac7afe655934ae5b0d3faf7b2001ba951383d9e69baeb1fdc879c81e4542f8ceb47c7044fb5266cdddbc0db6 > commons-lang3-3.14.0-bom.json=cce914a85f156c5757df5e6c28b9964f0be04f92035557491dd37dbef28efa812c4e975c391c38e2bfe807a530585ab666e40b544f76cc7ad9fb8a04c6012fbd > commons-lang3-3.14.0-bom.xml=51a55d0d1bcd2f093cb2f0b84870b2381ab9da740582cba04ae02ea6e50a97e0656bd2bc2871a8d6a7fc313f033ab70544134845dec193552ef9ecc8db3a0ecb > commons-lang3-3.14.0-javadoc.jar=40b1d2b1fe6a621d715d1290096942107f1d1bbb41a51096c70292be0803d5a6f9214fd8b5810ad154848d20bb498871ae9d2f8ad11649f0affaaa00f7c8e25c > commons-lang3-3.14.0-sources.jar=16363e06b52908ecbec9a62f4b1e0a39cf3de9c646504f0cee5bbe845739cbfb99f01438808bab2c407fc72d4adf212487886422415d9972614c5ee96273deab > commons-lang3-3.14.0-src.tar.gz=1ee4176c3588c11594a79f416a1f34b063cddb10c2124a37640fee48e5d8135091573002b6bf1eda5a60a324c1125665dadc93f9bfda32c9270c35113b6e1bea > commons-lang3-3.14.0-src.zip=8c1cc37e2be29e71cfb80775c4887b2c6cd466ef05bb59a4afc11bc5fbe9b253dc57bda5e29b05ca6f1e9b497d84c56a5573c1e64b659a43bedcbe5bc3105b11 > commons-lang3-3.14.0-test-sources.jar=dd8d9670cf91b4504804f855c74c75109060c86e87eeb5c56f31ff9241ffde272855fac21ce456303dac1578e5c58238cb59e0e628854ae9d4f1451e15f969b8 > commons-lang3-3.14.0-tests.jar=e5cc518ba310db0a20361502a0bb8896f05f0c0552b8170a37485922030e15a1221e9e027753ad522202af2326664cb2f0c14d409bac6bfe44b9065fc07bbc02 > > I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P > japicmp clean package site deploy' > > using: > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > Maven home: /usr/local/Cellar/maven/3.9.5/libexec > Java version: 21.0.1, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac" > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct > 9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64 > > Details of changes since 3.13.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/index.html > (note some *relative* links are broken and the 3.14.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.13.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > >
Re: [VOTE] Release Apache Commons Lang 3.14.0 based on RC1
[x] +1 Release these artifacts Building fine on Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) Maven home: /opt/apache-maven-3.8.5 Java version: 17.0.8.1, vendor: Private Build, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-88-generic", arch: "amd64", family: "unix" Site generated OK, inspected dist area archives and found no issues, site reports look good too. Thanks! On Sat, 18 Nov 2023 at 16:15, Gary Gregory wrote: > We have fixed a few bugs and added some enhancements since Apache > Commons Lang 3.13.0 was released, so I would like to release Apache > Commons Lang 3.14.0. > > Apache Commons Lang 3.14.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1 > (svn revision 65412) > > The Git tag commons-lang-3.14.0-RC1 commit for this RC is > c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-lang.git > --branch <https://gitbox.apache.org/repos/asf/commons-lang.git--branch> > commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1674/org/apache/commons/commons-lang3/3.14.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Nov 18 10:03:24 EST 2023 > Apache\ Commons\ > > Lang-3.14.0.spdx.rdf.xml=497cb8e231b7c3421f4ed27063f889c1ff9815d5cc76aa992d7c1f166ffe0ced0313e3a8daf17d0f2eb412ee4ce8923fb87b7abd6e897a6180005d9ce2c97b15 > > commons-lang3-3.14.0-bin.tar.gz=8e7e62418a49ba810512c13a640a8bf35f878fcd54af32fdaabe37817f58b21b475980ba663fba4887e45ef8d88af8ff17796f20d202e929e8e2574546dc > > commons-lang3-3.14.0-bin.zip=444ef65dfe130fdb50450778c757a23ccb16fdf4ac7afe655934ae5b0d3faf7b2001ba951383d9e69baeb1fdc879c81e4542f8ceb47c7044fb5266cdddbc0db6 > > commons-lang3-3.14.0-bom.json=cce914a85f156c5757df5e6c28b9964f0be04f92035557491dd37dbef28efa812c4e975c391c38e2bfe807a530585ab666e40b544f76cc7ad9fb8a04c6012fbd > > commons-lang3-3.14.0-bom.xml=51a55d0d1bcd2f093cb2f0b84870b2381ab9da740582cba04ae02ea6e50a97e0656bd2bc2871a8d6a7fc313f033ab70544134845dec193552ef9ecc8db3a0ecb > > commons-lang3-3.14.0-javadoc.jar=40b1d2b1fe6a621d715d1290096942107f1d1bbb41a51096c70292be0803d5a6f9214fd8b5810ad154848d20bb498871ae9d2f8ad11649f0affaaa00f7c8e25c > > commons-lang3-3.14.0-sources.jar=16363e06b52908ecbec9a62f4b1e0a39cf3de9c646504f0cee5bbe845739cbfb99f01438808bab2c407fc72d4adf212487886422415d9972614c5ee96273deab > > commons-lang3-3.14.0-src.tar.gz=1ee4176c3588c11594a79f416a1f34b063cddb10c2124a37640fee48e5d8135091573002b6bf1eda5a60a324c1125665dadc93f9bfda32c9270c35113b6e1bea > > commons-lang3-3.14.0-src.zip=8c1cc37e2be29e71cfb80775c4887b2c6cd466ef05bb59a4afc11bc5fbe9b253dc57bda5e29b05ca6f1e9b497d84c56a5573c1e64b659a43bedcbe5bc3105b11 > > commons-lang3-3.14.0-test-sources.jar=dd8d9670cf91b4504804f855c74c75109060c86e87eeb5c56f31ff9241ffde272855fac21ce456303dac1578e5c58238cb59e0e628854ae9d4f1451e15f969b8 > > commons-lang3-3.14.0-tests.jar=e5cc518ba310db0a20361502a0bb8896f05f0c0552b8170a37485922030e15a1221e9e027753ad522202af2326664cb2f0c14d409bac6bfe44b9065fc07bbc02 > > I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P > japicmp clean package site deploy' > > using: > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > Maven home: /usr/local/Cellar/maven/3.9.5/libexec > Java version: 21.0.1, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac" > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct > 9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64 > > Details of changes since 3.13.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/index.html > (note some *relative* links are broken and the 3.14.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.13.0): > > https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org
[VOTE] Release Apache Commons Lang 3.14.0 based on RC1
We have fixed a few bugs and added some enhancements since Apache
Commons Lang 3.13.0 was released, so I would like to release Apache
Commons Lang 3.14.0.
Apache Commons Lang 3.14.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1
(svn revision 65412)
The Git tag commons-lang-3.14.0-RC1 commit for this RC is
c8774fa74adbbbcd4e5f915ab6bc3aa10d877419 which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=c8774fa74adbbbcd4e5f915ab6bc3aa10d877419
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-lang.git
--branch commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1674/org/apache/commons/commons-lang3/3.14.0/
These are the artifacts and their hashes:
#Release SHA-512s
#Sat Nov 18 10:03:24 EST 2023
Apache\ Commons\
Lang-3.14.0.spdx.rdf.xml=497cb8e231b7c3421f4ed27063f889c1ff9815d5cc76aa992d7c1f166ffe0ced0313e3a8daf17d0f2eb412ee4ce8923fb87b7abd6e897a6180005d9ce2c97b15
commons-lang3-3.14.0-bin.tar.gz=8e7e62418a49ba810512c13a640a8bf35f878fcd54af32fdaabe37817f58b21b475980ba663fba4887e45ef8d88af8ff17796f20d202e929e8e2574546dc
commons-lang3-3.14.0-bin.zip=444ef65dfe130fdb50450778c757a23ccb16fdf4ac7afe655934ae5b0d3faf7b2001ba951383d9e69baeb1fdc879c81e4542f8ceb47c7044fb5266cdddbc0db6
commons-lang3-3.14.0-bom.json=cce914a85f156c5757df5e6c28b9964f0be04f92035557491dd37dbef28efa812c4e975c391c38e2bfe807a530585ab666e40b544f76cc7ad9fb8a04c6012fbd
commons-lang3-3.14.0-bom.xml=51a55d0d1bcd2f093cb2f0b84870b2381ab9da740582cba04ae02ea6e50a97e0656bd2bc2871a8d6a7fc313f033ab70544134845dec193552ef9ecc8db3a0ecb
commons-lang3-3.14.0-javadoc.jar=40b1d2b1fe6a621d715d1290096942107f1d1bbb41a51096c70292be0803d5a6f9214fd8b5810ad154848d20bb498871ae9d2f8ad11649f0affaaa00f7c8e25c
commons-lang3-3.14.0-sources.jar=16363e06b52908ecbec9a62f4b1e0a39cf3de9c646504f0cee5bbe845739cbfb99f01438808bab2c407fc72d4adf212487886422415d9972614c5ee96273deab
commons-lang3-3.14.0-src.tar.gz=1ee4176c3588c11594a79f416a1f34b063cddb10c2124a37640fee48e5d8135091573002b6bf1eda5a60a324c1125665dadc93f9bfda32c9270c35113b6e1bea
commons-lang3-3.14.0-src.zip=8c1cc37e2be29e71cfb80775c4887b2c6cd466ef05bb59a4afc11bc5fbe9b253dc57bda5e29b05ca6f1e9b497d84c56a5573c1e64b659a43bedcbe5bc3105b11
commons-lang3-3.14.0-test-sources.jar=dd8d9670cf91b4504804f855c74c75109060c86e87eeb5c56f31ff9241ffde272855fac21ce456303dac1578e5c58238cb59e0e628854ae9d4f1451e15f969b8
commons-lang3-3.14.0-tests.jar=e5cc518ba310db0a20361502a0bb8896f05f0c0552b8170a37485922030e15a1221e9e027753ad522202af2326664cb2f0c14d409bac6bfe44b9065fc07bbc02
I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P
japicmp clean package site deploy'
using:
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 21.0.1, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac"
Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct
9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64
Details of changes since 3.13.0 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/changes-report.html
Site:
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/index.html
(note some *relative* links are broken and the 3.14.0 directories
are not yet created - these will be OK once the site is deployed.)
JApiCmp Report (compared to 3.13.0):
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/japicmp.html
RAT Report:
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/site/rat-report.html
KEYS:
https://downloads.apache.org/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)
For following is intended as a helper and refresher for reviewers.
Validating a release candidate
==
These guidelines are NOT complete.
Requirements: Git, Java, Maven.
You can validate a release from a release candidate (RC) tag as follows.
1a) Clone and checkout the RC tag
git clone https://gitbox.apache.org/repos/asf/commons-lang.git
--branch commons-lang-3.14.0-RC1 commons-lang-3.14.0-RC1
cd commons-lang-3.14.0-RC1
1b) Download and unpack the source archive from:
https://dist.apache.org/repos/dist/dev/commons/lang/3.14.0-RC1/source
2) C
Re: [lang] DurationFormatUtils does not calculate duration for some specific dates and times
Please ignore the email. I need to pass the TimeZone for calculation,
otherwise it was taking the system default timezone which changes during
DayLight Saving.
Thanks,
Sujan
On Mon, 6 Nov 2023 at 16:35, Sujan Biswas wrote:
> Hi Team,
>
> Please find the below test case and observation which seems to be a bug in
> the DurationFormatUtils class. If you look at the calculated duration it
> says "Duration : *00-1113023530*" with output format as
> MMddHHmmssSSS.
>
> org.apache.commons
> commons-lang3
> 3.12.0
> provided
>
> @Test
> void getElapsedTimerTest() {
>
> String DATE_TIME_FORMAT = "MMddHHmmssSSS";
> long startEpochMillis = 1698541052000L; //Date and time (GMT): Sunday, 29
> October 2023 00:57:32
> long endEpochMillis = 1698544232000L; //Date and time (GMT): Sunday, 29
> October 2023 01:50:32
>
> String duration = DurationFormatUtils.formatPeriod(startEpochMillis,
> endEpochMillis, DATE_TIME_FORMAT);
>
> System.out.println("Start Time : " + Instant.ofEpochMilli
> (startEpochMillis));
> System.out.println("End Time : " + Instant.ofEpochMilli(endEpochMillis));
> System.out.println("Duration : " + duration);
>
>
> }
>
> Console Output:
>
> Start Time : 2023-10-29T00:57:32Z End Time : 2023-10-29T01:50:32Z Duration
> : *00-1113023530*
>
> Regards,
> Sujan Biswas
>
[lang] DurationFormatUtils does not calculate duration for some specific dates and times
Hi Team,
Please find the below test case and observation which seems to be a bug in
the DurationFormatUtils class. If you look at the calculated duration it
says "Duration : *00-1113023530*" with output format as
MMddHHmmssSSS.
org.apache.commons
commons-lang3
3.12.0
provided
@Test
void getElapsedTimerTest() {
String DATE_TIME_FORMAT = "MMddHHmmssSSS";
long startEpochMillis = 1698541052000L; //Date and time (GMT): Sunday, 29
October 2023 00:57:32
long endEpochMillis = 1698544232000L; //Date and time (GMT): Sunday, 29
October 2023 01:50:32
String duration = DurationFormatUtils.formatPeriod(startEpochMillis,
endEpochMillis, DATE_TIME_FORMAT);
System.out.println("Start Time : " + Instant.ofEpochMilli(startEpochMillis))
;
System.out.println("End Time : " + Instant.ofEpochMilli(endEpochMillis));
System.out.println("Duration : " + duration);
}
Console Output:
Start Time : 2023-10-29T00:57:32Z End Time : 2023-10-29T01:50:32Z Duration
: *00-1113023530*
Regards,
Sujan Biswas
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
I opened a PR after changing the expected failure probability to 1e-5. I had an old version of the GH build file when I estimated it used 4 runs. The latest CI runs 4 JDKs on 3 platforms plus CodeQL and coverage. So this is 14 runs. We should see failures with a probability of: (1 - (1 - 1e-5)**14) = 0.0001399, or approximately 1 in 7143. Compare that to previously: (1 - (1 - 1e-3)**14) = 0.01391, or approximately 1 in 71.89. If this is still a problem moving forward then we can replace with a fixed random number generator calling the underlying method and test coverage of the original method by other means. Alex On Fri, 20 Oct 2023 at 20:16, Gary D. Gregory wrote: > > Hi Alex, > > I'd prefer if you could give a shot at adjusting this test when you can take > the time. > > TY, > Gary > > On 2023/10/20 18:17:35 Alex Herbert wrote: > > On Fri, 20 Oct 2023 at 18:55, Alex Herbert wrote: > > > > > > The chi-square critical value (13.82) is correct: > > > > > > >>> from scipy.stats import chi2 > > > >>> chi2(2).isf(0.001) > > > 13.815510557964274 > > > > > > The test seems to fail with the expected frequency when run locally. I > > > annotated with: > > > > > > @RepeatedTest(value = 10) > > > > > > I observe 93 failures (just under 1 in 1000). So it is strange this > > > fails a lot on the GH CI build. > > > > > > We could just use a fixed Random argument to the call that is > > > ultimately performing the random string generation: > > > > > > random(count, 0, chars.length, false, false, chars, random()); > > > > > > Switch the test to: > > > > > > Random rng = new Random(0xdeadbeef) > > > > > > gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng); > > > > > > You will see a drop in coverage by not exercising the public API. > > > > > > The alternative is to change the chi-square critical value: > > > > > > 1 in 10,000: 18.420680743952364 > > > 1 in 100,000: 23.025850929940457 > > > 1 in 1,000,000: 27.631021115928547 > > > > > > Alex > > > > Also note that although the test fails 1 in 1000 times, we run 4 > > builds in CI (coverage + 3 JDKS). So we expect to see failure with a > > p-value of: > > > > 1 - (1 - 0.001)^4 = 0.00399 > > > > This is the probability of not seeing a failure subtracted from 1. It > > is approximately 1 in 250. > > > > I did check the computation of the chi-square statistic and AFAIK it is > > correct. > > > > My suggestion for a first change is to bump the critical value to the > > level for 1 in 100,000. We should then see failures every 25,000 GH > > builds. If the frequency is more than that then we have to assume that > > the ThreadLocalRandom instance is not uniformly sampling from the set > > of size 3. I find this unlikely as the underlying algorithm for > > ThreadLocalRandom is good [1]. > > > > Alex > > > > [1] IIRC it passes the Test U01 BigCrush test for random generators > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
Hi Alex, I'd prefer if you could give a shot at adjusting this test when you can take the time. TY, Gary On 2023/10/20 18:17:35 Alex Herbert wrote: > On Fri, 20 Oct 2023 at 18:55, Alex Herbert wrote: > > > > The chi-square critical value (13.82) is correct: > > > > >>> from scipy.stats import chi2 > > >>> chi2(2).isf(0.001) > > 13.815510557964274 > > > > The test seems to fail with the expected frequency when run locally. I > > annotated with: > > > > @RepeatedTest(value = 10) > > > > I observe 93 failures (just under 1 in 1000). So it is strange this > > fails a lot on the GH CI build. > > > > We could just use a fixed Random argument to the call that is > > ultimately performing the random string generation: > > > > random(count, 0, chars.length, false, false, chars, random()); > > > > Switch the test to: > > > > Random rng = new Random(0xdeadbeef) > > > > gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng); > > > > You will see a drop in coverage by not exercising the public API. > > > > The alternative is to change the chi-square critical value: > > > > 1 in 10,000: 18.420680743952364 > > 1 in 100,000: 23.025850929940457 > > 1 in 1,000,000: 27.631021115928547 > > > > Alex > > Also note that although the test fails 1 in 1000 times, we run 4 > builds in CI (coverage + 3 JDKS). So we expect to see failure with a > p-value of: > > 1 - (1 - 0.001)^4 = 0.00399 > > This is the probability of not seeing a failure subtracted from 1. It > is approximately 1 in 250. > > I did check the computation of the chi-square statistic and AFAIK it is > correct. > > My suggestion for a first change is to bump the critical value to the > level for 1 in 100,000. We should then see failures every 25,000 GH > builds. If the frequency is more than that then we have to assume that > the ThreadLocalRandom instance is not uniformly sampling from the set > of size 3. I find this unlikely as the underlying algorithm for > ThreadLocalRandom is good [1]. > > Alex > > [1] IIRC it passes the Test U01 BigCrush test for random generators > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
On Fri, 20 Oct 2023 at 18:55, Alex Herbert wrote: > > The chi-square critical value (13.82) is correct: > > >>> from scipy.stats import chi2 > >>> chi2(2).isf(0.001) > 13.815510557964274 > > The test seems to fail with the expected frequency when run locally. I > annotated with: > > @RepeatedTest(value = 10) > > I observe 93 failures (just under 1 in 1000). So it is strange this > fails a lot on the GH CI build. > > We could just use a fixed Random argument to the call that is > ultimately performing the random string generation: > > random(count, 0, chars.length, false, false, chars, random()); > > Switch the test to: > > Random rng = new Random(0xdeadbeef) > > gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng); > > You will see a drop in coverage by not exercising the public API. > > The alternative is to change the chi-square critical value: > > 1 in 10,000: 18.420680743952364 > 1 in 100,000: 23.025850929940457 > 1 in 1,000,000: 27.631021115928547 > > Alex Also note that although the test fails 1 in 1000 times, we run 4 builds in CI (coverage + 3 JDKS). So we expect to see failure with a p-value of: 1 - (1 - 0.001)^4 = 0.00399 This is the probability of not seeing a failure subtracted from 1. It is approximately 1 in 250. I did check the computation of the chi-square statistic and AFAIK it is correct. My suggestion for a first change is to bump the critical value to the level for 1 in 100,000. We should then see failures every 25,000 GH builds. If the frequency is more than that then we have to assume that the ThreadLocalRandom instance is not uniformly sampling from the set of size 3. I find this unlikely as the underlying algorithm for ThreadLocalRandom is good [1]. Alex [1] IIRC it passes the Test U01 BigCrush test for random generators - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
The chi-square critical value (13.82) is correct: >>> from scipy.stats import chi2 >>> chi2(2).isf(0.001) 13.815510557964274 The test seems to fail with the expected frequency when run locally. I annotated with: @RepeatedTest(value = 10) I observe 93 failures (just under 1 in 1000). So it is strange this fails a lot on the GH CI build. We could just use a fixed Random argument to the call that is ultimately performing the random string generation: random(count, 0, chars.length, false, false, chars, random()); Switch the test to: Random rng = new Random(0xdeadbeef) gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng); You will see a drop in coverage by not exercising the public API. The alternative is to change the chi-square critical value: 1 in 10,000: 18.420680743952364 1 in 100,000: 23.025850929940457 1 in 1,000,000: 27.631021115928547 Alex On Fri, 20 Oct 2023 at 18:44, Elliotte Rusty Harold wrote: > > It's possible the chi square test is miscalculated. Perhaps some stats > expert can check that. It's also possible the chi square test isn't > the right one to use here. Again, consult a stats expert. > > It's also very possible that the randomness is not nearly as random as > it's supposed to be. That's incredibly common, and that might be > noticeable given the very short three-letter character set [a, b, c] > being picked from. > > On Fri, Oct 20, 2023 at 1:31 PM Gary D. Gregory wrote: > > > > Despite the failure comment: > > > > RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- > > will fail about 1 in 1000 times ==> expected: but was: > > > > This test fails a LOT more than once every 1000 times, based on how many > > GitHub builds I need to restart every week. > > > > What can be done to make this test more resilient? > > > > TY! > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
It's possible the chi square test is miscalculated. Perhaps some stats expert can check that. It's also possible the chi square test isn't the right one to use here. Again, consult a stats expert. It's also very possible that the randomness is not nearly as random as it's supposed to be. That's incredibly common, and that might be noticeable given the very short three-letter character set [a, b, c] being picked from. On Fri, Oct 20, 2023 at 1:31 PM Gary D. Gregory wrote: > > Despite the failure comment: > > RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- will > fail about 1 in 1000 times ==> expected: but was: > > This test fails a LOT more than once every 1000 times, based on how many > GitHub builds I need to restart every week. > > What can be done to make this test more resilient? > > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
