[
https://issues.apache.org/jira/browse/THRIFT-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522069#comment-17522069
]
Tian Jiang edited comment on THRIFT-5483 at 4/14/22 5:41 AM:
-------------------------------------------------------------
Yes, defining a separate key is just my current solution for the problem. But
since a struct may have (logically) immutable fields that just make it suitable
to be a key, it is natural to try to use them directly as keys. After all,
introducing unnecessary encapsulation is not desired in performance-urgent
scenarios. And as all keys in Java are used by reference, it is not likely that
the footprints of keys matter, as long as they are also used elsewhere.
Well, this may be too far from the start point. My initial intention is: now
that Thrift provides default implementations of `hashCode` and `compareTo`
which involve all fields, why not make it more practical since it may not
always be the desired order. If a user cannot decide on fields to be compared,
is it really helpful to generate such functions automatically?
In short, there are two questions:
1. Why generate a default comparator with all fields in the first place?
2. Does it bring any harm to making the comparator customizable?
was (Author: jt2594838):
Yes, defining a separate key is just my current solution for the problem. But
since a struct may have (logically) immutable fields that just make it suitable
to be a key, it is natural to try to use them directly as keys. After all,
introducing unnecessary encapsulation is not desired in performance-urgent
scenarios. And as all keys in Java are used by reference, it is not likely that
the footprints of keys matter, as long as they are also used elsewhere.
Well, this may be too far from the start point. My initial intention is: now
that Thrift provides default implementations of `hashCode` and `compareTo`
which involve all fields, why not make it more practical since it may not
always be the desired order. If a user cannot decide on fields to be compared,
is it really helpful to generate such functions automatically?
> Support customized comparator in Java
> -------------------------------------
>
> Key: THRIFT-5483
> URL: https://issues.apache.org/jira/browse/THRIFT-5483
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Compiler
> Reporter: Tian Jiang
> Priority: Trivial
> Attachments: screenshot-1.png
>
>
> The generated comparator (and hash code) of Thrift Structs compares two
> objects by all of their fields, which may cause trouble when used in hash
> structures.
> For example, I define a struct like:
> {code:java}
> struct Person{
> 1: required i64 id
> 2: required string phoneNumber
> }
> {code}
> The id of a Person is final, while its phoneNumber can be changed.
> Then I use it as a key in a map to record a Person's supervisors:
> {code:java}
> Map<Person, Person> supervisorMap;
> {code}
> Apparently, as the generated comparator of Person will use both id and
> phoneNumber for comparison and hash if I change the phoneNumber of a Person,
> I can no longer get it from the map as its hash value changes and it will be
> distributed to another hash slot.
> Therefore, I wish I could specify the fields that are to be used in
> comparator and hash code generation. One preferable grammar may be like:
> {code:java}
> struct Person{
> 1: required comparable i64 id
> 2: required string phoneNumber
> }
> {code}
> Then the generated comparator and hash code will only use fields marked with
> `comparable`, and if no fields are marked with comparable, Java's default
> comparison and hashcode (using object address) will be used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
