Why shouldn't we use Object.hashCode() by default, even if the equals check is done by comparing byte arrays? Wouldn't it be faster?
On Fri, Jan 27, 2017 at 4:38 AM, Pavel Tupitsyn <[email protected]> wrote: > Makes sense to me. > > Ticket for reference: https://issues.apache.org/jira/browse/IGNITE-4558 > > On Fri, Jan 27, 2017 at 1:37 PM, Vladimir Ozerov <[email protected]> > wrote: > > > Folks, > > > > Historically we have fundamental flaw in how we deal with hashCode/equals > > for BinaryObjects: > > 1) hashCode() is taken from original deserialized object. > > 2) But equals() is performed through binary array comparison. > > > > We recently introduced BinaryIdentityResolver [1] as a part of DML > feature, > > but we didn't change any existing semantics, because it might broke > > applications running AI 1.x. > > > > Now I am thinking on how it should be designed properly in AI 2.0, and > here > > is my idea: > > 1) Every type will use BinaryArrayIdentityResolver [2] unless it is > > overridden in config > > 2) Hash code is calculated only using resolver > > 3) Equality is determined only using resolver > > 4) Never ever use Object.hashCode(). > > > > This way we will have clean and consistent hashCode/equals semantics. > > > > Any objections or comments? > > > > Vladimir. > > > > [1] > > https://github.com/apache/ignite/blob/master/modules/ > > core/src/main/java/org/apache/ignite/binary/BinaryIdentityResolver.java > > [2] > > https://github.com/apache/ignite/blob/master/modules/ > > core/src/main/java/org/apache/ignite/binary/BinaryArrayIdentityResolver. > > java > > >
