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 noticed some strange behavior of the current AnnotatedMember.equals() implementations. Following test case for AnnotatedConstructor.equals() currently fails:
Based on the first two successful assertEquals(...) statements, I would have expected that the third assertEquals(...) should be also successful. However, it currently fails.
The reason for this behavior is that AnnotatedConstructor.equals() is currently using == for comparing the two constructors:
public boolean equals(Object o) {
if (o == this) return true;
return ClassUtil.hasClass(o, getClass())
&& (((AnnotatedConstructor) o)._constructor == _constructor);
}
However, the implementation of the reflection API in java.lang.Class is always copying / cloning the Field, Method and Constructor instances prior to returning them to the caller (e.g. see Class.copyConstructors()). Thus, each call of Class.getConstructors() will always return new instances.
If you agree that the above test case should be successful (i.e. also assertEquals(instance1.getDefaultConstructor(), instance2.getDefaultConstructor()) should be successful), I would prepare a corresponding pull request that slightly modifies the current implementation of the equals() method for all subclasses of AnnotatedMember that are affected by this problem (i.e. at least AnnotatedField, AnnotatedConstructor and AnnotatedMethod).
The text was updated successfully, but these errors were encountered:
klaasdellschaft
changed the title
Behavior of AnnotatedMember.equals() vs AnnotatedClass.equals()
Behavior of AnnotatedMember.equals()Jun 25, 2021
@klaasdellschaft I think you are right: I was assuming that instances would be equal.
Now... Jackson itself is probably not using equality check for anything (given there is no known issue) but it does seem like it'd make sense to implement equality checks properly. So I'd be happy to review a PR.
For fields (for example) it'd be simple enough: same name, same class Field is declared in; for methods enough to check name, declaring class, and match of type-erased parameter types.
klaasdellschaft
added a commit
to klaasdellschaft/jackson-databind
that referenced
this issue
Jul 1, 2021
Hi,
I noticed some strange behavior of the current
AnnotatedMember.equals()
implementations. Following test case forAnnotatedConstructor.equals()
currently fails:Based on the first two successful
assertEquals(...)
statements, I would have expected that the thirdassertEquals(...)
should be also successful. However, it currently fails.The reason for this behavior is that
AnnotatedConstructor.equals()
is currently using==
for comparing the two constructors:However, the implementation of the reflection API in
java.lang.Class
is always copying / cloning theField
,Method
andConstructor
instances prior to returning them to the caller (e.g. seeClass.copyConstructors()
). Thus, each call ofClass.getConstructors()
will always return new instances.If you agree that the above test case should be successful (i.e. also
assertEquals(instance1.getDefaultConstructor(), instance2.getDefaultConstructor())
should be successful), I would prepare a corresponding pull request that slightly modifies the current implementation of theequals()
method for all subclasses ofAnnotatedMember
that are affected by this problem (i.e. at leastAnnotatedField
,AnnotatedConstructor
andAnnotatedMethod
).The text was updated successfully, but these errors were encountered: