Improve the way Equals and Hashcode are generated

[jharmelink]

No description provided.

[joelittlejohn]

Excellent. Thanks for looking at this Jan, every user will benefit from this.

Could you squash these changes into one commit and try to remove any unnecessary formatting?

One final thing - do you have any comment on the backwards compatibility of this change? Is the behaviour (e.g. where subclasses are concerned) functionally equivalent to the original reflectionHashCode and reflectionEquals calls? If not, this may not be a blocker, but we should add an extra note to the release notes.

[jharmelink]

OK, no problem. I'll look into it tomorrow.

[jharmelink]

Sorry I couldn't look into it before you merged it. The past few weeks have ben rather hectic. I'm also thinking about making the fields to use in the hashcode and equals generation configurable in the future. What do you think of that idea?

[steowens]

Been away for quite some time and apologies in advance from the peanut gallery. Personally I like the idea of having a configurable set of options on the way that hashcode and equals are built. Trying to keep them functionally equivalent to Reflections hashcode builder and equals is not in my opinion desirable. There are many times where you would want to generate pojo classes for which equality is based on only a subset of the properties of the pojo. For example when using a subset of properties as a unique key to index the pojo when storing in a mongo reposotiry.