5

I just came across a code using EqualsBuilder() in equals method. Is there any advantage of using it instead of writing (or generating from eclipse) our own logic? A simple example would be more helful.

Edit : If it doesn't have any benefits than having less code in the class, isn't there is overhead of reflection?

Vallabh Patade
  • 4,960
  • 6
  • 31
  • 40
  • possible duplicate of [Apache Commons equals/hashCode builder](http://stackoverflow.com/questions/5038204/apache-commons-equals-hashcode-builder) – souser Jul 30 '14 at 20:24

4 Answers4

5

There are a few ways to approach this.

  1. You can roll your own - that has the highest likelihood of getting something subtle wrong.

  2. You can have Eclipse generate your equals and hashCode methods for you - that leaves a lot of code in place, subject to inadvertent edits, and subject to failure to update when the class acquires a new field.

  3. You can use EqualsBuilder; it avoids the aforementioned problems.

  4. Best of all, at least in my experience, you can use lombok's EqualsAndHashCode annotation.

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
  • 1
    comparing fields for equals() is highly error-prone as transient fields may very well carry volatile yet important information - ignoring these in equals() WILL result in data-loss as two objects which have been modified in near-parallel will get classified as equal , effectively deleting results and negating already-invested computing-power - in the worst case this may even crash your whole application if it depends on sequential, complete result-parsing of object-permutations. – specializt Jul 30 '14 at 20:55
  • 3
    @specializt: For normal practice, I stand by the advice in the answer. There are certainly very rare special situations which call for other approaches, but your comment is misleadingly extreme and provocative. – Carl Manaster Jul 30 '14 at 20:59
  • 1
    these "very rare special situation" are actually everyday-situations and the ONLY way of storing data without loss. Databases work that way (PRIMARYKEY), filesystems work that way (filename & timestamp) and whatnot ... its a basic IT-concept. Sorry, apparently you guys missed quite a few things. Identity ALWAYS has to be centered on one, single point of information, no matter how extensive this information is. You would'nt be able to type these words without your keys in your keyboard having "absolute" (if that is even possible) identities. – specializt Jul 30 '14 at 21:04
0

Using an EqualsBuilder is not implicitly better or worse than writing your equals method from scratch. In other words, I don't consider using EqualsBuilder to be a best practice.

A non-EqualsBuilder equals() method usually looks like this:

public boolean equals(Object other) {
    boolean result;

    if(this == other)
        result = true;
    else
    if(other == null)
        result = false;
    else
    if(other instanceof MyClass) {
        MyClass o=(MyClass) other;
        result = Objects.equals(this.a, o.a)
                 && Objects.equals(this.b, o.b)
                 // ...
                 && Objects.equals(this.z, o.z);
    }
    else
        result = false;

    return result;
}
sigpwned
  • 6,957
  • 5
  • 28
  • 48
  • So why did they come up with EqualsBuilder.? – Vallabh Patade Jul 30 '14 at 20:27
  • I think you meant "inherently," not "implicitly." – yshavit Jul 30 '14 at 20:28
  • Are we arguing word choice in the comments? Define *[implicitly](https://www.google.com/search?q=define%20implicitly)*: without qualification: absolutely. If you think it's important, feel free to submit an edit for moderation. – sigpwned Jul 30 '14 at 20:39
  • @VallabhPatade hard to say. Someone probably thought it was less error prone, easier, or more readable. I don't personally find `ErrorBuilder` to be that useful or important, but certainly others may! – sigpwned Jul 30 '14 at 20:41
  • Objects.equals was only introduced with Java 7. EqualsBuilder predates Java 7. – GaZ Nov 19 '14 at 09:45
0

I don't see need for example. Equals builder will generate exactly same code for you so the only difference is that you have less code in a class.

From my perspective it's better to write those methods (as you always have to override hashCode when you override equals)

Michal Gruca
  • 522
  • 3
  • 6
-2

Using ANYTHING except for your own implementation in equals() is GUARANTEED to be "worse" if you can use ... say a strictly unique ID.

If your ID is really unique you will most likely have the best, possible implementation with this, of course it needs to be polished quite a bit:

@Override
public boolean equals(Object other)
{
   if(other instanceof MyClass)
   {
      MyClass obj = (MyClass)other;
      return obj.getID() == this.getID();
   }
   else
      return false;
}

Have a look at this, this and especially this

specializt
  • 1,913
  • 15
  • 26