• - Use super class Methods(toString(), equals() and hashCode())
• - Don’t use super class Methods (toString(), equals(), and hashCode())
• - Use super class Methods (Only if superclass is not “java.lang.Object”)

The third option is the default setting. I think this is very helpful. Nevertheless, these options do not eliminate the need for class comparison. Without a class comparison option the generated code can still violate symmetry. This plugin should err on the side of caution by using class comparison by default. ‘instanceof’ comparison should be an option rather than the default. Thank you for your excellent comments.

And here is one more point about equals implementation. I see you used “instanceof” test which has the implication that you want a subclass object be considered the same as the superclass object if it has the same field values used in the equals test. This can lead to equality unsymmetry where if a subclass overwrites the equals method using “if (object instanceof PersonWithGuavaSubclass)” you will run into situation where subObject.equals(superObject) will always be false but superObject.equals(subObject) might return with true.

I find it sometimes helpful to NOT consider them the same by testing equality on the actual class names of the subclass and superclass.

This approach, will help insure symmetry where if a subclass overwrites the equals method to use some new additional fields in the test, you can ensure that subObject.equals(superObject) is the same as superObject.equals(subObject).