<div dir="auto"><div>Thank you to Stuart, Michel, and Joe for taking care of closing my enhancement and adding helpful comments, I appreciate it!<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 11, 2024, 5:13 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace" class="gmail_default">Since I am abandoning this idea, could someone close my JBS ticket?</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">And please link this message in the core-libs-dev archives as the close reason -- I fear the potential for misuse, as mentioned in previous emails on this thread.</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default"><a href="https://bugs.openjdk.org/browse/JDK-8324718" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8324718</a></div><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 11, 2024 at 5:10 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace">Hello,</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Thank you for your response!</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">So, I had thought of that before posting this email, and mentally, I had hand-waved away the concern by saying that there were plenty of situations where equality would still be useful without hashing. And while I still very much feel the same, the way you phrased your question is making me realize that my proposal could double nicely as a foot gun.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Like you said -- Java's concept of equality is often attached to the concept of hashing. And while the 2 are permitted to exist out of alignment with each other, handling the asymmetric relationship is a dangerous balancing act that is error-prone.</div><div><br></div><div><div style="font-family:monospace">I fear that this method would be handing developer a foot gun. There already exists a large number of bugs caused by misalignment between equals and hashCode, and I see how this method would contribute to exactly that problem. Understanding that, I myself don't feel comfortable pushing this method forward.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">That said, I do appreciate you , <a class="gmail_plusreply" id="m_592769570412980168m_7356214055576735706m_-6898397706320460825m_5115459772829523376m_3868254267435778063m_-5759937818913068630plusReplyChip-1" href="mailto:philip.race@oracle.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@Philip Race</a> , <a class="gmail_plusreply" id="m_592769570412980168m_7356214055576735706m_-6898397706320460825m_5115459772829523376m_3868254267435778063m_-5759937818913068630plusReplyChip-2" href="mailto:Alan.Bateman@oracle.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@Alan Bateman</a> , and <a class="gmail_plusreply" id="m_592769570412980168m_7356214055576735706m_-6898397706320460825m_5115459772829523376m_3868254267435778063m_-5759937818913068630plusReplyChip-3" href="mailto:liangchenblue@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@-</a> for being helpful as I go through the process. If nothing else, this was educational, and I now know exactly what concerns my next proposal should keep in mind when I try again.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">And I see the value of "socializing", as <a class="gmail_plusreply" id="m_592769570412980168m_7356214055576735706m_-6898397706320460825m_5115459772829523376m_3868254267435778063m_-5759937818913068630plusReplyChip-4" href="mailto:Alan.Bateman@oracle.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@Alan Bateman</a> put it. I had thought this idea through plenty, but I can only see from my perspective.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Thank you all for your time and help!</div><div style="font-family:monospace">David Alayachew<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 11, 2024 at 3:26 AM Holo The Sage Wolf <<a href="mailto:holo3146@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">holo3146@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">How beneficial is it to extend equality method without appropriate hashing?</div><div dir="auto"><br></div><div dir="auto">Specifically, given you are working in a domain specific world, e.g. projection of Point3D into XY with equality semantics of equalsByXY, Java does not know how to treat semantically equal objects as equal:</div><div dir="auto"><br></div><div dir="auto">var foo = new Point3D(0,0,0);</div><div dir="auto">var bar = new Point3D(0,0,1);</div><div dir="auto">var set = new HashSet<>(Arrays.asList(foo, bar));</div><div dir="auto">assert set.size() == 1 \\ assertion failure :(</div><div dir="auto"><br></div><div dir="auto">The idea is fine, but you need to wrap a lot of Java's Standard Library to respect the new semantics.</div><div dir="auto"><br></div><div dir="auto">I think that the idea can work nicely as a library, but not inside java.*</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, 11 Feb 2024, 07:41 David Alayachew, <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace">Hello Core Libs Dev Team,</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">I jumped the gun a bit and made a PR for this first. Alan Bateman kindly informed me of my faux pas, and now I'm trying to redo things correctly.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">I am looking to add a new method to java.util.Objects to facilitate equality checks, something that I hope fits well in place with the other methods in this class.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Here is my basic idea. (Special thanks to @liach for guidance in creating this!)</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">```java<br>import java.util.*;<br>import java.util.function.*;<br><br>import static java.util.Objects.*;<br><br>public class Objects2<br>{<br><br> public static <T> BiPredicate<T, T> equalsBy(final List<Function<T, ?>> functions)<br> {<br> <br> requireNonNull(functions, "Objects.equalsBy cannot execute because the parameter is null!");<br> <br> return<br> (final T o1, final T o2) -><br> {<br> <br> requireNonNull(o1, "Cannot check for equality because the first object is null!");<br> requireNonNull(o2, "Cannot check for equality because the second object is null!");<br> <br> for (final var function : functions)<br> {<br> <br> requireNonNull(function, "Cannot check for equality because the
function
is null!");<br> <br> final var r1 = function.apply(o1);<br> final var r2 =
function.apply(o2);<br> <br> final boolean theyAreEqual = Objects.equals(r1, r2);<br> <br> if (!theyAreEqual)<br> {<br> <br> return false;<br> <br> }<br> <br> }<br> <br> return true;<br> <br> }<br> ;<br> <br> }<br><br> public static void main(final String[] args)<br> {</div><div style="font-family:monospace"><br></div><div style="font-family:monospace"> record Point3D(int x, String y, int z) {}<br> <br> final Point3D a = new Point3D(1, "2", 3);<br> final Point3D b = new Point3D(1, "2", 4);<br> <br> final BiPredicate<Point3D,Point3D> equalsByXY = equalsBy(List.of(Point3D::x, Point3D::y));<br> final BiPredicate<Point3D,Point3D> equalsByXYZ = equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));<br> <br> System.out.println(equalsByXY.test(a, b)); //true<br> System.out.println(equalsByXYZ.test(a, b)); //false<br> <br> }<br><br>}<br></div><div style="font-family:monospace">```</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">The concept is simple -- I want to make it easy to create ad-hoc equals methods.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Object equality is domain-specific -- in some domains, 2 objects are equal, but in another, they are not. The object's equals method is not always a good spot to put this logic into, largely because we don't always know what domain we are in. The object's equals method is where a good default should be placed, not logic for every domain. And even if we tried, it's difficult, if not impossible, to apply equality for the correct domain if both objects are of the same type.<br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">So, for domain-specific contexts, I would like to introduce this method. This method (which should be constant-foldable, thanks again for the help @liach!) lets you clearly say that you are taking 2 objects and comparing them by the following methods that apply to both. And due to the nature of lambdas, developers are not constrained to just the getters of the object in question -- any function that takes in T is fair game. This allows flexibility, and lets developers keep their objects simple, thus facilitating things like DOP.<br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Now, perhaps this makes more sense on the BiPredicate interface instead. However, since this was more equality focused, I figured Objects was a better fit.<br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Any thoughts? <br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Thank you all for your time and help!</div><div style="font-family:monospace">David Alayachew<br></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div></div>