Hi Steve,
Thanks for the kind words!
What you should do in this case, kind of depends on what your intention is. I noticed that Sventon1 basically has the same implementation of equals as AbstractSventon: no new fields are added into the mix. If it's indeed your intention to only add behaviour to Sventon, and not data, you could simply remove the equals override in Sventon1 (and make it final in AbstractSventon). That completely satisfies the equals contract, and it also satisfies EqualsVerifier (which is more strict than the contract). It does mean, however, that any subclass of AbstractSventon could be equal to any other subclass. This also satisfies the Liskov substitution principle, that says that any class (in this case, Sventon1, Sventon2 and SventonX) should be able to transparently stand in for its superclass (AbstractSventon).
If you don't mean to add new fields, but you don't want Sventon1 to be able to be equal to Sventon2, you could write your equals using getClass() instead of instanceof:
@Override
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
AbstractSventon that = (AbstractSventon) o;
return new EqualsBuilder().append(url, that.url)
.append(repositoryInstance, that.repositoryInstance)
.isEquals();
}
Then add .usingGetClass() to your call to EqualsVerifier, and you're set. The downside to this is, you can't make trivial subclasses of Sventon1 anymore (for example, if you just want to quickly override one method in an anonymous subclass). Hibernate does this a lot, too. Your equals method will appear to be broken, because these trivial (and often nameless) subclasses suddenly are no longer equal to other instances of Sventon1. If you run into this problem, you should add a canEqual method to AbstractSventon. How to do this, is excellently explained in this article:
http://www.artima.com/lejava/articles/equality.html
Hope this helps! If you have any more questions, please let me know.
Jan