Rancho-7 commented on PR #18782: URL: https://github.com/apache/kafka/pull/18782#issuecomment-2639113421
> How are you evaluating if these classes can be safely converted? There are clear differences in behavior in equals/hashCode after these changes. Hi @ijuma Thanks for catching this issue.You make a good point about the different behaviors in equals/hashCode. While the [Java SE docs](https://docs.oracle.com/javase/specs/jls/se17/html/jls-8.html#jls-8.3) mention these differences: > - A method public final boolean equals(Object) that returns true if and only if the argument is an instance of R, and the current instance is equal to the argument instance at every record component of R; otherwise false is returned. > - A method public final int hashCode() that returns a hash code value derived from the hash code values at every record component of R. in our implementation we're actually comparing the object fields directly rather than using equals() for object comparison.E.g: https://github.com/apache/kafka/blob/852f14065b9a7084560b4864eba30ac343bbd6a6/coordinator-common/src/main/java/org/apache/kafka/coordinator/common/runtime/CoordinatorExecutorImpl.java#L96 https://github.com/apache/kafka/blob/852f14065b9a7084560b4864eba30ac343bbd6a6/group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupMetadataManager.java#L2505 And we don't invoke hashCode() directly either. Based on this approach, I believe these conversions should maintain compatibility without issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
