You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work on search engine based on Apache Lucene, and want to use EqualsVerifier to check equals and hashCode implementations in custom queries. Because bugs here could break query cache what may be hidden until very production.
// Here methods and field from org.apache.lucene.search.Query:protectedfinalbooleansameClassAs(Objectother) {
returnother != null && getClass() == other.getClass();
}
privatefinalintCLASS_NAME_HASH = getClass().getName().hashCode();
protectedfinalintclassHash() {
returnCLASS_NAME_HASH;
}
// Here how they use it, copied from org.apache.lucene.search.KnnVectorQuery:@Overridepublicbooleanequals(Objectobj) {
if (sameClassAs(obj) == false) {
returnfalse;
}
return ((KnnVectorQuery) obj).k == k
&& ((KnnVectorQuery) obj).field.equals(field)
&& Arrays.equals(((KnnVectorQuery) obj).target, target)
&& Objects.equals(filter, ((KnnVectorQuery) obj).filter);
}
@OverridepublicinthashCode() {
returnObjects.hash(classHash(), field, k, Arrays.hashCode(target), filter);
}
And EqualsVerifier report such problem:
Significant fields: hashCode relies on CLASS_NAME_HASH, but equals does not.
These objects are equal, but probably shouldn't be
Asking to ignore CLASS_NAME_HASH field doesn't help.
Because EqualsVerifier find out that CLASS_NAME_HASH affects on hashCode and doesn't affect on equals.
Which looks like contract violation, but CLASS_NAME_HASH effectively static (getClass().getName().hashCode()) and works like salt for hashCode.
Problem:
I work on search engine based on Apache Lucene, and want to use EqualsVerifier to check
equals
andhashCode
implementations in custom queries. Because bugs here could break query cache what may be hidden until very production.Here how Query equals and hashCode calculation is done in Lucene:
And EqualsVerifier report such problem:
Asking to ignore
CLASS_NAME_HASH
field doesn't help.Because EqualsVerifier find out that
CLASS_NAME_HASH
affects onhashCode
and doesn't affect onequals
.Which looks like contract violation, but
CLASS_NAME_HASH
effectively static (getClass().getName().hashCode()
) and works like salt forhashCode
.You could reproduce it with Lucene like that:
Possible solution:
Support such salt-like logic by adding method
SingleTypeEqualsVerifierApi#withSaltFields(String[])
Alternative solution:
Alternatively could be better to add more general method
SingleTypeEqualsVerifierApi#useDefaultValuesForFields(String[])
.The text was updated successfully, but these errors were encountered: