[lang] New approach to tackle issue LANG-332: EqualsBuilder to alternatively use method properties

[Miguel Munoz <sw...@yahoo.com.INVALID>]

I have a new approach to write a reflection-equals utility that will likely execute noticeably faster than the current approach. It will also let us add new strategies, such as an EqualsBuilder to use method properties, as requested in issue LANG-332. It will also allow us to add whatever other new strategies developers may propose.
A class that uses my new approach to determine equality and return hash codes might look something like this:
     public class Widget implements Comparable<Widget> {         // Fields, properties, and methods go here           private static final Reflector<Widget> reflector = Reflector.buildPropertyReflector(Widget.class)                 .includeTransientProperties(trPropertyName1, trPropertyName2)                 .exclude(propertyName1)                 .build();
           @Override public boolean equals(Object other) {             return reflector.doEquals(this, other);         }           @Override public int hashCode() {             return reflector.doHashCode(this);         }     }

There are three main advantages to doing it this way:
1. By creating the reflector class at class-load time, we speed up the process of comparing the instances. With the current EqualsBuilder class, much of the work to implement equals() gets duplicated each time it gets called.
2. It simplifies the user's task of writing the equals method. The user no longer needs to start each equals() method like this:
  public boolean equals(Object obj) {        if (obj == null) { return false; }       if (obj == this) { return true; }        if (obj.getClass() != getClass()) {        return false;                          }      ...  }                                  
  Instead, all this work will be done in the call to reflector.doEquals(this, other)
3. The approach will make it easier to add new strategies. The example above calls the buildPropertyReflector() method. Other methods may be written to implement other approaches. For example, another strategy could be added that would also generate a compareTo() method, to implement the Comparable implementation that's consistent with equals() and hashCode(). This would probably involve annotations that can be used to specify the comparison order of the various fields or properties.
I've written a class like this before, so I know it works, and I know the pitfalls. In short, I would like you to assign the LANG-332 task to me.
-- Miguel Muñoz