Tbh, I was really surprised to find out that in Java8 the code did indeed also
introspect internal fields of all those java.util.* foundation classes. It's
imo pure luck that it did work so well for a decade for anything Set, List,
Map, etc.
Working on a patch with all those discussed changes.
The next question is whether any of this should be mentioned/recorded in
the Javadoc or at least in a code comment.
Gary
On Fri, Mar 8, 2024, 5:24 AM Mark Struberg
wrote:
> Hi Gary!
>
> Yes, this would be really slow. Plus after further thinking about it, I
> guess it doesn't add anything over
Hi Daniel!
Yes, you are right. As written in my mail to Gary: I think it would be enough
for now if we'd come to the same results as before the module privacy
restrictions. If we do better later on it is an optional bonus.
LieGrue,
strub
> Am 07.03.2024 um 15:39 schrieb Daniel Watson :
>
> O
Hi Gary!
Yes, this would be really slow. Plus after further thinking about it, I guess
it doesn't add anything over the required existing behaviour imo. Until now
reflectionEquals did simply dig into the Class.getDeclaredFields of those
java.util.* classes. So it only did compare the EXAKT same
One comment about the collection comparison...
For any collection that actually implements List, equality should *include*
order, not attempt to ignore it, right? The contract of a list is that the
order is consistent, and two lists with the same items in different order,
should not be considered
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 th
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
> th
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 t
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
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
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. F
11 matches
Mail list logo
