Make the fields used in hashcode and equals generation configurable

[d4rxh4wx]

#241 (comment)

[ltoinel]

+1

[joelittlejohn]

Hi all, how would you propose configuring this? Would you like to add a field to each property, have a global configuration value containing a list of field names, or do something like include only 'required' fields?

[d4rxh4wx]

Hi. I would go with a list of field names. In that way, you can see in one place which fields are participating to equals and hashcode.

[joelittlejohn]

@d4rxh4wx do you mean in the object itself? like:

{
  "type" : "object",
  "javaHashcodeEqualsFields" : ["foo","bar"]
}

[d4rxh4wx]

Yes. That sounds good.

[MikaelElkiaer]

+1

How about an option for using super classes' fields for equals and hashCode?

Edit: Another option could be to completely leave out equals and hashCode if a class extends another class. (At least this is viable in my case, as I have a unique identifier field in my super-class)

[skarian92]

Hi
So any updates on the problem.How can I configure HashcodeEqualFields??

[rozhok]

+1
Also I don't like to include dependency to commons-lang and want to see plain java8 equals/hashCode like

@Override
public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (o == null || getClass() != o.getClass()) {
        return false;
    }
    Message that = (Message) o;
    return Objects.equals(type, that.type) &&
            Arrays.equals(updated, that.updated) &&
            Arrays.equals(deleted, that.deleted) &&
            Objects.equals(content, that.content);
}

@Override
public int hashCode() {
    return Objects.hash(type, updated, deleted, content);
}

[szhem]

+1

I'd like hashcode, equals and toString with java8 style too

[joelittlejohn]

We now have equals, hashCode and toString methods that do not depend on commons-lang, and we also allow fields to be excluded from these (see excludedFromEqualsAndHashCode schema extension).