equals works incorrectly for Java Records if some fields are initialized with null

[foal]

If some fields in java record are initialized with null the equals return false.

public record A(String v) {}

boolean equals1 = new A("A").equals(new A("A"));
boolean equals2 = new A(null).equals(new A(null));

Both equals1 and equals2 have to be true but equals2 is false

GWT 2.13.0

[niloc132]

From my comments when I implemented it:

          // We would like to use Objects.equals here to be more concise, but we would need
          // to look up the right impl based on the field - just as simple to insert a null check
          // and get it a little closer to all being inlined away

"Just" to insert a null check... and an equality check. Too bad I didnt actually look at Objects.equals when I wrote it.

Confirmed via a simple unit test, I'll || in a simple this.foo == that.foo check. We already have a dependency on Objects for hash(Object...), so that might be better.

The "right impl" note appears to refer to the unofficial String overload - that probably should be backed by @SpecializeMethod anyway, which would allow it to be renamed and still function correctly.

[mP1]

why not use the null aware Objects.equals which internally handles the given samples ?

[niloc132]

From the comment I quoted - because it complicates the compiler code because there is an overload that has to be distinguished to resolve the correct method.

If we correctly mark the string overload as a string specialization of the other method and rename it, we shouldn't have that extra hurdle.

[niloc132]

Method specialization doesn't work quite as nicely here - the compiler has already removed its params by the time we get here, we need to be a bit more clever to make it work. Actual usage works - but simple test can to be too simple and the compiler assumes no string is equal to any other string... I'll keep working on this another day.

[foal]

@niloc132 Do you have any estimates regarding fix and 2.13.1 release?

[niloc132]

I do not - our policy is always "when its ready", and there are no security fixes pending. #10292 is broken with latest FF - I have a "it seems to work" fix, but am still working on getting unit tests to pass.

[niloc132]

@foal / @mP1 2.13.1-SNAPSHOT is available if you can confirm this, that will help us get closer to shipping a release with the fix.