Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

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 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
 

Re: [VOTE] Release Apache Commons Compress 1.26.1 based on RC1

[Gary Gregory]

My +1

Gary

On Tue, Mar 5, 2024 at 5:40 PM Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons Compress 1.26.1.
>
> Apache Commons Compress 1.26.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1
> (svn revision 67751)
>
> The Git tag commons-compress-1.26.1-RC1 commit for this RC is
> 81ac94151eedc61c2131239362a051e30c5e9e59 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=81ac94151eedc61c2131239362a051e30c5e9e59
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> --branch commons-compress-1.26.1-RC1 commons-compress-1.26.1-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1700/org/apache/commons/commons-compress/1.26.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Mar 05 22:24:25 UTC 2024
> Apache\ Commons\
> Compress-1.26.1.spdx.rdf.xml=7dd9d7ad576dea9611f87acd8b047f4b0f9701730a7cdcc62a3800b04f3ef7aa889e80c7df2a1636aa44f8fd58462c5bf3b19dc2c0004490009faef1ac2301b9
> commons-compress-1.26.1-bin.tar.gz=56325ec491bc5e6d8c37742d5f44869a9668f8359d5243cf8628dfb06f223bc3c1133239185295df4a98f8503f32f7609cecdbe24cc0f15fdd34a577bab0d7b9
> commons-compress-1.26.1-bin.zip=217838bad31682bb29b4f5eafad2ec5bf767a0c417fec2f16e84e2a6af7ed8fb44a34ad81c382a88155f0688988c58b85280411cf00a0f7022ccd89e83fbd3b5
> commons-compress-1.26.1-bom.json=9ddb2350681af3e6378e7fa5c35ae2916b07dc429adb25b96a07a72b095fa0db81e59904aaab4b6c48856ab9c77c64dadd414d652b1b0aa8e22494354f3937b7
> commons-compress-1.26.1-bom.xml=0fcaa44fd3393be32cfdf37e8678554a4fb9bfae90a6ab20975ef48493df6a7cab7fc79ac1c821e538daa18ecfe4d29c0f9aa27ccff63dbcfe3d588dd26e5d91
> commons-compress-1.26.1-javadoc.jar=5de00b4eedc3e9f9343c165b11d23e3a0d42c3681890707888af5c3257e15c1d3af35c1bb924c4b86fa8ce5398116b4eb61aeb32fec3181a339857fd305c934d
> commons-compress-1.26.1-sources.jar=65cbf8d1db3c150f76c5c4afec5f874253a18d89df7afff24ad93097507ddb52edaf47829863f4a0f561d547879c52c75a7bd590476e6911b6614000a0eaa58d
> commons-compress-1.26.1-src.tar.gz=096c94344a9bbcd021a3cce0869456cf6d22ca5136b63de017922d7c3de5d94b591961fe550201b654f9dc90b2cd8f32ef9bf1e507fddfb2e2f7c33bddc790c4
> commons-compress-1.26.1-src.zip=69387bd46fe25b5b046819d41804f3b9c867b598a2d408e1131f34ba33ccf3589cce07ef3f360da5c60a5b455e7084aca3a0722ab75de67279babf5fa7c65280
> commons-compress-1.26.1-test-sources.jar=08d2729412759a5e2c3a07619e807b67ac57dc29bdd69d24114dfc467e1ca2589837150db18195510d19accb1604b8c77987e85bb1787dfec3be441b0980c54c
> commons-compress-1.26.1-tests.jar=d2af16e04a0d5f8c1de0d23c1c4b035ebf20598bb6c9c1f7ea5858605804a35bb7b70b0e8f42bf735303d916f9fe1d2292b36838ca8912e2d70f89ec88261da4
>
> I have tested this with:
>
> mvn
>
> and
>
> mvn -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 1.26.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/index.html
> (note some *relative* links are broken and the 1.26.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.26.0):
> 
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/japicmp.html
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-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 

Re: [VOTE] Release Apache Commons Compress 1.26.1 based on RC1

[Melloware Inc]

+1 (non-binding)

I only checked it out and tested it locally with our application.

On Tue, Mar 5, 2024 at 5:43 PM Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons Compress 1.26.1.
>
> Apache Commons Compress 1.26.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1
> (svn revision 67751)
>
> The Git tag commons-compress-1.26.1-RC1 commit for this RC is
> 81ac94151eedc61c2131239362a051e30c5e9e59 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=81ac94151eedc61c2131239362a051e30c5e9e59
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> --branch
> 
> commons-compress-1.26.1-RC1 commons-compress-1.26.1-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1700/org/apache/commons/commons-compress/1.26.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Mar 05 22:24:25 UTC 2024
> Apache\ Commons\
>
> Compress-1.26.1.spdx.rdf.xml=7dd9d7ad576dea9611f87acd8b047f4b0f9701730a7cdcc62a3800b04f3ef7aa889e80c7df2a1636aa44f8fd58462c5bf3b19dc2c0004490009faef1ac2301b9
>
> commons-compress-1.26.1-bin.tar.gz=56325ec491bc5e6d8c37742d5f44869a9668f8359d5243cf8628dfb06f223bc3c1133239185295df4a98f8503f32f7609cecdbe24cc0f15fdd34a577bab0d7b9
>
> commons-compress-1.26.1-bin.zip=217838bad31682bb29b4f5eafad2ec5bf767a0c417fec2f16e84e2a6af7ed8fb44a34ad81c382a88155f0688988c58b85280411cf00a0f7022ccd89e83fbd3b5
>
> commons-compress-1.26.1-bom.json=9ddb2350681af3e6378e7fa5c35ae2916b07dc429adb25b96a07a72b095fa0db81e59904aaab4b6c48856ab9c77c64dadd414d652b1b0aa8e22494354f3937b7
>
> commons-compress-1.26.1-bom.xml=0fcaa44fd3393be32cfdf37e8678554a4fb9bfae90a6ab20975ef48493df6a7cab7fc79ac1c821e538daa18ecfe4d29c0f9aa27ccff63dbcfe3d588dd26e5d91
>
> commons-compress-1.26.1-javadoc.jar=5de00b4eedc3e9f9343c165b11d23e3a0d42c3681890707888af5c3257e15c1d3af35c1bb924c4b86fa8ce5398116b4eb61aeb32fec3181a339857fd305c934d
>
> commons-compress-1.26.1-sources.jar=65cbf8d1db3c150f76c5c4afec5f874253a18d89df7afff24ad93097507ddb52edaf47829863f4a0f561d547879c52c75a7bd590476e6911b6614000a0eaa58d
>
> commons-compress-1.26.1-src.tar.gz=096c94344a9bbcd021a3cce0869456cf6d22ca5136b63de017922d7c3de5d94b591961fe550201b654f9dc90b2cd8f32ef9bf1e507fddfb2e2f7c33bddc790c4
>
> commons-compress-1.26.1-src.zip=69387bd46fe25b5b046819d41804f3b9c867b598a2d408e1131f34ba33ccf3589cce07ef3f360da5c60a5b455e7084aca3a0722ab75de67279babf5fa7c65280
>
> commons-compress-1.26.1-test-sources.jar=08d2729412759a5e2c3a07619e807b67ac57dc29bdd69d24114dfc467e1ca2589837150db18195510d19accb1604b8c77987e85bb1787dfec3be441b0980c54c
>
> commons-compress-1.26.1-tests.jar=d2af16e04a0d5f8c1de0d23c1c4b035ebf20598bb6c9c1f7ea5858605804a35bb7b70b0e8f42bf735303d916f9fe1d2292b36838ca8912e2d70f89ec88261da4
>
> I have tested this with:
>
> mvn
>
> and
>
> mvn -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 1.26.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/index.html
> (note some *relative* links are broken and the 1.26.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.26.0):
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-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 

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[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 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

[VOTE] Release Apache Commons Configuration 2.10.0 based on RC1

[Gary Gregory]

We have fixed a few bugs and added some enhancements since Apache
Commons Configuration 2.9.0 was released, so I would like to release
Apache Commons Configuration 2.10.0.

Apache Commons Configuration 2.10.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.0-RC1
(svn revision 67757)

The Git tag commons-configuration-2.10.0-RC1 commit for this RC is
67637998d398d79bf0cc6b830d72fadd8b53a355 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=67637998d398d79bf0cc6b830d72fadd8b53a355
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.10.0-RC1
commons-configuration-2.10.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1701/org/apache/commons/commons-configuration2/2.10.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Wed Mar 06 14:01:58 UTC 2024
commons-configuration2-2.10.0-bin.tar.gz=4239219274c9e59f897870bf5cbf35210885b2812d74c15c79b1150cb1d0617ebcbc5417c99019addd75a14da67807fb78ca55efe2c8b48b6251584bde051d15
commons-configuration2-2.10.0-bin.zip=36ea60c2dc927ef06c02c6694278dcd799cb5c9a6902314061347c2ac787bf8dbb7c0fa59f6e39c298352e401b1e5dd82c5214a08354639cbf80044220750df5
commons-configuration2-2.10.0-bom.json=02fc0b438d1189035f7049bc010961e5309cab6cead5c37fabf2294556fa5e0a9fd223fe3f4a1564fc83e261500905d0795105906ce3fa71df0613f9b746b37c
commons-configuration2-2.10.0-bom.xml=6bbda2ba6c2f0d7af8fd7fee93c71fb3f29a1fb220598cda8d3bbf2dfe19396364a63a6109b5418390da7b41f5e9a2eeaaae1f2fd4ce707d44bee38b19b23409
commons-configuration2-2.10.0-javadoc.jar=0494fb1bfeabaa246ad7507dc8464c78e76a0223767817123bdf8843aaf56030af512da9feac499fbfee79eaeb4d4cbe6749a28a679a531b0bc6301b711ddf3a
commons-configuration2-2.10.0-sources.jar=bacf3d4538810e095fccdb51479b5739082c97a8fc2572b887b542cc6551583da64cd2104387d9872e990e02af0419e7986b532bb007ae710d118549a046df89
commons-configuration2-2.10.0-src.tar.gz=fa0959160b85a686886275624b9a7b8cb38480bc502cc930669d97c521cccddc4b2371a01bab85ecb2f88dfe6d1c22558b6525eeabc5b8cf9070163d24ff031b
commons-configuration2-2.10.0-src.zip=e61c68feaddbfddf0985ba904ac5f73c4420b7fb7fdd173a83efd320673df7c3b652120ef6e513572a0c7c8bf5935d934187411b2ab124c5d03ba9072ab02ca3
commons-configuration2-2.10.0-test-sources.jar=bff3d3e30e1352c759e148641989b65129c235da70ec85b428c3876981b6bace7a00fd65f8b896ee649ba984869635a03ebe28f03226e62d9771db1373686ae9
commons-configuration2-2.10.0-tests.jar=1fe44c1f1c49e0846836141286d874ac641523bfac4403defc1af2ff8910660189a21c56a255f9e3fc2e4737e644259b23aa22a4bdaffd3296436c6cf1aea44e
org.apache.commons_commons-configuration2-2.10.0.spdx.json=d6329228f13ca56b811ae6f2fae9fb9dd841d4efd6f0c52847728d8fbea44dac67ce1dbad9e766e4a237e06cd99d220cb76c64e3ef4898aa0047a4556411c37b

I have tested this with:

mvn

and

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

Using:

openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 21.0.2)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 21.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Details of changes since 2.9.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.0-RC1/site/index.html
(note some *relative* links are broken and the 2.10.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.9.0):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.10.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 

Re: [VOTE] Release Apache Commons Compress 1.26.1 based on RC1

[Rob Tompkins]

+1 tested builds on java 8 -21, site - reports all look good, RELEASE-NOTES.txt 
good, signatures good.

> On Mar 5, 2024, at 5:40 PM, Gary Gregory  wrote:
> 
> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons Compress 1.26.1.
> 
> Apache Commons Compress 1.26.1 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1
> (svn revision 67751)
> 
> The Git tag commons-compress-1.26.1-RC1 commit for this RC is
> 81ac94151eedc61c2131239362a051e30c5e9e59 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=81ac94151eedc61c2131239362a051e30c5e9e59
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> --branch commons-compress-1.26.1-RC1 commons-compress-1.26.1-RC1
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1700/org/apache/commons/commons-compress/1.26.1/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Tue Mar 05 22:24:25 UTC 2024
> Apache\ Commons\
> Compress-1.26.1.spdx.rdf.xml=7dd9d7ad576dea9611f87acd8b047f4b0f9701730a7cdcc62a3800b04f3ef7aa889e80c7df2a1636aa44f8fd58462c5bf3b19dc2c0004490009faef1ac2301b9
> commons-compress-1.26.1-bin.tar.gz=56325ec491bc5e6d8c37742d5f44869a9668f8359d5243cf8628dfb06f223bc3c1133239185295df4a98f8503f32f7609cecdbe24cc0f15fdd34a577bab0d7b9
> commons-compress-1.26.1-bin.zip=217838bad31682bb29b4f5eafad2ec5bf767a0c417fec2f16e84e2a6af7ed8fb44a34ad81c382a88155f0688988c58b85280411cf00a0f7022ccd89e83fbd3b5
> commons-compress-1.26.1-bom.json=9ddb2350681af3e6378e7fa5c35ae2916b07dc429adb25b96a07a72b095fa0db81e59904aaab4b6c48856ab9c77c64dadd414d652b1b0aa8e22494354f3937b7
> commons-compress-1.26.1-bom.xml=0fcaa44fd3393be32cfdf37e8678554a4fb9bfae90a6ab20975ef48493df6a7cab7fc79ac1c821e538daa18ecfe4d29c0f9aa27ccff63dbcfe3d588dd26e5d91
> commons-compress-1.26.1-javadoc.jar=5de00b4eedc3e9f9343c165b11d23e3a0d42c3681890707888af5c3257e15c1d3af35c1bb924c4b86fa8ce5398116b4eb61aeb32fec3181a339857fd305c934d
> commons-compress-1.26.1-sources.jar=65cbf8d1db3c150f76c5c4afec5f874253a18d89df7afff24ad93097507ddb52edaf47829863f4a0f561d547879c52c75a7bd590476e6911b6614000a0eaa58d
> commons-compress-1.26.1-src.tar.gz=096c94344a9bbcd021a3cce0869456cf6d22ca5136b63de017922d7c3de5d94b591961fe550201b654f9dc90b2cd8f32ef9bf1e507fddfb2e2f7c33bddc790c4
> commons-compress-1.26.1-src.zip=69387bd46fe25b5b046819d41804f3b9c867b598a2d408e1131f34ba33ccf3589cce07ef3f360da5c60a5b455e7084aca3a0722ab75de67279babf5fa7c65280
> commons-compress-1.26.1-test-sources.jar=08d2729412759a5e2c3a07619e807b67ac57dc29bdd69d24114dfc467e1ca2589837150db18195510d19accb1604b8c77987e85bb1787dfec3be441b0980c54c
> commons-compress-1.26.1-tests.jar=d2af16e04a0d5f8c1de0d23c1c4b035ebf20598bb6c9c1f7ea5858605804a35bb7b70b0e8f42bf735303d916f9fe1d2292b36838ca8912e2d70f89ec88261da4
> 
> I have tested this with:
> 
> mvn
> 
> and
> 
> mvn -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> using:
> 
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
> 
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
> 
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
> 
> Details of changes since 1.26.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/index.html
>(note some *relative* links are broken and the 1.26.1 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 1.26.0):
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/japicmp.html
> 
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-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 

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

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

[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
>
>

[LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

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