frankvicky commented on PR #18783:
URL: https://github.com/apache/kafka/pull/18783#issuecomment-2637459446

   Hi @ijuma 
   Thanks for the reminder. It's indeed an issue that I should research first, 
especially for such underlying implementation and hot path related change. I 
will keep that in mind. ๐Ÿ™‡๐Ÿผ 
   
   Back to the question, I have read [Java 17 SE 
spec](https://docs.oracle.com/javase/specs/jls/se17/html/jls-8.html#jls-8.10). 
Following is the statement:
   
   > Equality of an instance a of a record class R with another instance b of 
the same record class at a record component c is determined as follows:
   If the type of the record component c is a reference type, equality is 
determined as follows: if the value of the component field c of both a and b is 
the null reference then true is returned; if the value of the component field c 
of either a or b, but not both, is the null reference then false is returned; 
otherwise equality is determined by invoking the equals method on the value of 
the component field c of a, with an argument that is the value of the component 
field c of b.
   If the type of the record component c is a primitive type T, equality is 
determined as if by invoking the static method compare of the wrapper class 
corresponding to T 
([ยง5.1.7](https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.7)),
 with the first argument given by the value of the component field c of a, and 
the second argument given by the value of the component field c of b; if the 
method would return 0 then true is returned, otherwise false is returned.
   
   According to the spec, the record's `equals` method behavior is basically 
the same as what we implemented before.
   Although primitive types don't directly use the `==` operator, the result is 
effectively the same. This can be seen in the `Integer.compare` implementation.
   
   
https://github.com/apache/kafka/blob/c215b8b645edf6769f4a8976edcf0cc380ded21b/server-common/src/main/java/org/apache/kafka/server/common/TopicIdPartition.java#L49-L54
   
   **Integer.compare:**
   ```java
       public static int compare(int x, int y) {
           return (x < y) ? -1 : ((x == y) ? 0 : 1);
       }
   ```
   
   > A method public final int hashCode() that returns a hash code value 
derived from the hash code values at every record component of R.
   The hash code value of an instance a of a record class at a record component 
c is as follows:
   If the type of the record component c is a reference type, then the hash 
code value is determined as if by invoking the hashCode method on the value of 
the component field c of a.
   
   According to the spec, the behavior of the record's `hashCode` method is 
basically the same as what we implemented before:
   
https://github.com/apache/kafka/blob/c215b8b645edf6769f4a8976edcf0cc380ded21b/server-common/src/main/java/org/apache/kafka/server/common/TopicIdPartition.java#L56-L59
   
   
   Therefore, the changes to `record` should be behavior-compatible. As for 
performance, since the underlying implementation remains essentially the same, 
there should not be significant performance differences.  ๐Ÿ™‡๐Ÿผ 


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to