[
https://issues.apache.org/jira/browse/CALCITE-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150461#comment-17150461
]
Haisheng Yuan commented on CALCITE-4096:
----------------------------------------
Flat2List is a good alternative.
However, that leads me to another question, why does Pair implement Map.Entry
interface in the first place?
In Calcite, there is no customized Map class that uses Pair as map entry.
Outside of Calcite, it sounds insane to use Calcite's Pair as third-party's
customized Map class's map entry.
If Pair is not used as any other Map's entry, comparing with other Map.Entry
doesn't make sense either. Even if Pair.hashCode comply Map.Entry's hashCode,
Pair.equals always require the other to be a Pair. Unless we want to support
when \{{otherEntry.equals(Pair)}} is true, but \{{Pair.equals(otherEntry)}} is
false.
BTW, RelDataTypeFieldImpl breaks Map.Entry's hashCode too. The original code of
hashCode was:
{code:java}
return index
^ name.hashCode()
^ type.hashCode();
{code}
And I saw hash collision of using this.
Pair is used as HashMap keys in several places of Calcite, some of them have
the same type on the left and right. More importantly, RelNode digest uses
Pair's hashCode to compute the digest's hashCode.
> Change Pair.hashCode() not to use XOR
> -------------------------------------
>
> Key: CALCITE-4096
> URL: https://issues.apache.org/jira/browse/CALCITE-4096
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> JDK Map Entry uses XOR maybe because it is unlikely to use Map Entry as the
> HashMap key.
> But Pair in Calcite is a general data structure, it is used in several places
> as the key of HashMap/HashSet. XOR is not a good candidate for hash
> algorithm, it is more likely to generate hash collision than simple prime
> multiplication, especially when pair.left equals pair.right.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
