IMO, The issue with this article is that it conflated a desire for immutable record types (as you'd see in a functional language) with something which requires

IMO, The issue with this article is that it conflated a desire for immutable record types (as you'd see in a functional language) with something which requires equivalence overloading in a language which does not support them (as you'd find in a heavy OO language). I think while he presented _A_ solution to the specific issue he encountered (wanting to compare algebraic types as cohesive units in Java), it is not the _best_ general solution to the issue - in fact, it's really not the best solution in any language without built-in record types, as it can lead to costly hidden comparison times and unneeded memory growth (which most design patterns I would say should discourage this kind of hidden performance issue). This is a data structure problem which should be attacked much like how a compiler implementer would attack it - by being lazy and doing at little work as possible. Instead of making similar objects appear equivalent - make identical objects be references to the same object! Since we already decided to let records be immutable, it actually turns out quite nicely in JS, as I have written elsewhere - and I'm confident that the same cached-reference/object interning strategy could be used in Java, too.