hashCode and equals (again)  
Author Message
Todd





PostPosted: 2008-4-9 22:51:00 Top

java-programmer, hashCode and equals (again) Hello,

I have spent a great deal of time reading through the postings in this
group as well as tutorials/explanations on sites elsewhere (i.e.,
Roedy's, etc.), but have not been able to get a good grasp of hashCode
and equals. I understand most of the rules for hashCode are defined
for use of objects in maps and other comparable collections, so it is
from that POV that I am trying to get a good grasp of the concepts.

Please help if you can - especially the SCCE later.

1. Originally, I thought that it made sense to make an equals method
that uses hashCode as its criteria for equality. However, as I now
understand hashCode, the code _must_ be the same for equal objects,
BUT it is _possible_ to be the same for non-equal objects. Am I
stating this correctly?

2. When would one use a set of criteria to determine equality that is
different from the criteria used to generate a hashCode?

3. Why aren't the hashCode_s in the following code the same?

package hashcode;

public class Main
{
public static void main(String[] args)
{

int[] a = { 1, 7, 0, 0 };
int[] b = { 1, 7, 0, 0 };

System.out.println( "equals: " + a.equals( b ) );
System.out.println( "hash a: " + a.hashCode() );
System.out.println( "hash b: " + b.hashCode() );


Integer[] c = { 1, 7, 0, 0 };
Integer[] d = { 1, 7, 0, 0 };

System.out.println( "equals: " + c.equals( d ) );
System.out.println( "hash c: " + c.hashCode() );
System.out.println( "hash d: " + d.hashCode() );


int[] e = a.clone();
Integer[] f = c.clone();

System.out.println( "equals: " + a.equals( e ) );
System.out.println( "hash a: " + a.hashCode() );
System.out.println( "hash e: " + e.hashCode() );
System.out.println( "equals: " + c.equals( f ) );
System.out.println( "hash c: " + c.hashCode() );
System.out.println( "hash f: " + f.hashCode() );
}

}

Thanks,
Todd
 
Todd





PostPosted: 2008-4-9 23:02:00 Top

java-programmer >> hashCode and equals (again) On Apr 9, 7:51 am, Todd <email***@***.com> wrote:
> Hello,
>
> I have spent a great deal of time reading through the postings in this
> group as well as tutorials/explanations on sites elsewhere (i.e.,
> Roedy's, etc.), but have not been able to get a good grasp of hashCode
> and equals. I understand most of the rules for hashCode are defined
> for use of objects in maps and other comparable collections, so it is
> from that POV that I am trying to get a good grasp of the concepts.
>
> Please help if you can - especially the SCCE later.
>
> 1. Originally, I thought that it made sense to make an equals method
> that uses hashCode as its criteria for equality. However, as I now
> understand hashCode, the code _must_ be the same for equal objects,
> BUT it is _possible_ to be the same for non-equal objects. Am I
> stating this correctly?
>
> 2. When would one use a set of criteria to determine equality that is
> different from the criteria used to generate a hashCode?
>
> 3. Why aren't the hashCode_s in the following code the same?
>
> package hashcode;
>
> public class Main
> {
> public static void main(String[] args)
> {
>
> int[] a = { 1, 7, 0, 0 };
> int[] b = { 1, 7, 0, 0 };
>
> System.out.println( "equals: " + a.equals( b ) );
> System.out.println( "hash a: " + a.hashCode() );
> System.out.println( "hash b: " + b.hashCode() );
>
> Integer[] c = { 1, 7, 0, 0 };
> Integer[] d = { 1, 7, 0, 0 };
>
> System.out.println( "equals: " + c.equals( d ) );
> System.out.println( "hash c: " + c.hashCode() );
> System.out.println( "hash d: " + d.hashCode() );
>
> int[] e = a.clone();
> Integer[] f = c.clone();
>
> System.out.println( "equals: " + a.equals( e ) );
> System.out.println( "hash a: " + a.hashCode() );
> System.out.println( "hash e: " + e.hashCode() );
> System.out.println( "equals: " + c.equals( f ) );
> System.out.println( "hash c: " + c.hashCode() );
> System.out.println( "hash f: " + f.hashCode() );
> }
>
> }
>
> Thanks,
> Todd

Question I forgot:
Should the hashCode be used as an equality criteria ~ as long as it is
combined with some other criteria?
 
Hendrik Maryns





PostPosted: 2008-4-9 23:24:00 Top

java-programmer >> hashCode and equals (again) This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Todd schreef:
> On Apr 9, 7:51 am, Todd <email***@***.com> wrote:
>> Hello,
>>
>> I have spent a great deal of time reading through the postings in this
>> group as well as tutorials/explanations on sites elsewhere (i.e.,
>> Roedy's, etc.), but have not been able to get a good grasp of hashCode
>> and equals. I understand most of the rules for hashCode are defined
>> for use of objects in maps and other comparable collections, so it is
>> from that POV that I am trying to get a good grasp of the concepts.
>>
>> Please help if you can - especially the SCCE later.
>>
>> 1. Originally, I thought that it made sense to make an equals method
>> that uses hashCode as its criteria for equality. However, as I now
>> understand hashCode, the code _must_ be the same for equal objects,
>> BUT it is _possible_ to be the same for non-equal objects. Am I
>> stating this correctly?

Yes. There generally is no need to make your equals() function that
complex, that it depends on hashCode()

>> 2. When would one use a set of criteria to determine equality that is
>> different from the criteria used to generate a hashCode?

If you are lazy and implement an easy hashCode(), but I wouldn鈥檛 see a
good reason of the top of my head.

>> 3. Why aren't the hashCode_s in the following code the same?

Arrays are objects. hashCode() for an array is the hashCode of Object,
which is simply based on its place in memory, it has nothing to do with
its contents. If you want the hashCode to depend on the objects in it,
use ArrayList or any other Collections class.

Similarly, equals() for arrays uses Object鈥檚 equals(), which is the same
as ==.

>> package hashcode;
>>
>> public class Main
>> {
>> public static void main(String[] args)
>> {
>>
>> int[] a = { 1, 7, 0, 0 };
>> int[] b = { 1, 7, 0, 0 };
>>
>> System.out.println( "equals: " + a.equals( b ) );
>> System.out.println( "hash a: " + a.hashCode() );
>> System.out.println( "hash b: " + b.hashCode() );
<snip>

> Question I forgot:
> Should the hashCode be used as an equality criteria ~ as long as it is
> combined with some other criteria?

The singular is 鈥榗riterion鈥? http://en.wiktionary.org/wiki/criteria
(luckily I looked that up, since I was wrong as well).

Isn鈥檛 that covered by your first question? I鈥檇 say 鈥榥o鈥?

public class Whatever {
int i, j;
@Override public boolean equals(Object other){
if (!other instanceof Whatever) {
return false;
}
Whatever otherWE = (Whatever) other;
return otherWE.i == i && otherWE.j == j;
}
@Override public int hashCode() {
return i;
}
}

Would be perfectly valid, although I would suggest to change hashCode to
something like
@Override public int hashCode() {
return i ^ j;
}
Experts will be able to tell you more about how to combine i and j,
there are some reasons for not using 鈥?鈥?

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html


 
 
rossum





PostPosted: 2008-4-9 23:29:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote:

>Hello,
>
>I have spent a great deal of time reading through the postings in this
>group as well as tutorials/explanations on sites elsewhere (i.e.,
>Roedy's, etc.), but have not been able to get a good grasp of hashCode
>and equals. I understand most of the rules for hashCode are defined
>for use of objects in maps and other comparable collections, so it is
>from that POV that I am trying to get a good grasp of the concepts.
>
>Please help if you can - especially the SCCE later.
Have a read of Chapter Three of "Effective Java":
http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf That
should help,


>
>1. Originally, I thought that it made sense to make an equals method
>that uses hashCode as its criteria for equality. However, as I now
>understand hashCode, the code _must_ be the same for equal objects,
>BUT it is _possible_ to be the same for non-equal objects. Am I
>stating this correctly?
Yes. In general there will be objects that have the same hash code
but are not equal. It would be possible to use the hash code as a
filter - if the hash codes are different then the objects are not
equal, but thet depends on the correct implementation of hashCode(),
as you have noticed in your third question.


>
>2. When would one use a set of criteria to determine equality that is
>different from the criteria used to generate a hashCode?
A hash code must be an integer, which sets a limit on how many
different hash codes there are. There are far more possible strings
than there are integers/hash codes, so different strings will have to
share the same hash code.

>
>3. Why aren't the hashCode_s in the following code the same?
>
>package hashcode;
>
>public class Main
>{
> public static void main(String[] args)
> {
>
> int[] a = { 1, 7, 0, 0 };
> int[] b = { 1, 7, 0, 0 };
>
> System.out.println( "equals: " + a.equals( b ) );
> System.out.println( "hash a: " + a.hashCode() );
> System.out.println( "hash b: " + b.hashCode() );
>
>
> Integer[] c = { 1, 7, 0, 0 };
> Integer[] d = { 1, 7, 0, 0 };
>
> System.out.println( "equals: " + c.equals( d ) );
> System.out.println( "hash c: " + c.hashCode() );
> System.out.println( "hash d: " + d.hashCode() );
>
>
> int[] e = a.clone();
> Integer[] f = c.clone();
>
> System.out.println( "equals: " + a.equals( e ) );
> System.out.println( "hash a: " + a.hashCode() );
> System.out.println( "hash e: " + e.hashCode() );
> System.out.println( "equals: " + c.equals( f ) );
> System.out.println( "hash c: " + c.hashCode() );
> System.out.println( "hash f: " + f.hashCode() );
> }
>
>}
What results are you expecting? Why are you expecting those results?

I get:

equals: false
hash a: 25345246
hash b: 4047035
equals: false
hash c: 5324129
hash d: 26530674
equals: false
hash a: 25345246
hash e: 29752800
equals: false
hash c: 5324129
hash f: 27165481

You might also try using Arrays.equals():

equals: false
Arrays.equals: true
hash a: 27692793
hash b: 32801378
equals: false
Arrays.equals: true
hash c: 26999600
hash d: 25706868
equals: false
Arrays.equals: true
hash a: 27692793
hash e: 8470547
equals: false
Arrays.equals: true
hash c: 26999600
hash f: 26596606

rossum

>Thanks,
>Todd

 
 
Eric Sosman





PostPosted: 2008-4-9 23:34:00 Top

java-programmer >> hashCode and equals (again) Todd wrote:
> Hello,
>
> I have spent a great deal of time reading through the postings in this
> group as well as tutorials/explanations on sites elsewhere (i.e.,
> Roedy's, etc.), but have not been able to get a good grasp of hashCode
> and equals. I understand most of the rules for hashCode are defined
> for use of objects in maps and other comparable collections, so it is
> from that POV that I am trying to get a good grasp of the concepts.
>
> Please help if you can - especially the SCCE later.
>
> 1. Originally, I thought that it made sense to make an equals method
> that uses hashCode as its criteria for equality. However, as I now
> understand hashCode, the code _must_ be the same for equal objects,
> BUT it is _possible_ to be the same for non-equal objects. Am I
> stating this correctly?

Right. "Objects are equal" implies "hashCodes are equal,"
but not necessarily the other way around. Think about it a
bit and you'll see why this must be so: a hashCode is an int
value, and there are "only" four billion different ints. Since
there are far, far more than four billion different Strings,
for example, they can't all have unique hashCodes; some Strings
that are different will have the same hashCode and are said
to "collide."

> 2. When would one use a set of criteria to determine equality that is
> different from the criteria used to generate a hashCode?

Rarely. You might have a class with several elements that
must agree if two instances are considered "equal," but perhaps
it would be inconvenient or expensive to compute hashCodes for
some of those elements. If so, you might decide to omit them
from your class' hashCode computation (although you would still
need to test their equality in your equals method). Usually,
though, it is advisable to include all the equality-determining
elements in the hashCode computation.

Note that the hashCode must *not* depend on anything that
is not part of the equality determination! Can you see why?

> 3. Why aren't the hashCode_s in the following code the same?
> [... hashCodes of arrays with identical content ...]

That's just the way Java is defined: two distinct arrays
are not "equal" just because they happen to have identical
content. One reason for this is that two arrays that have
the same content at one moment could have different content
a moment later; this would be inconvenient if the arrays were
already in a HashMap or in a Set or something. The Arrays
class provides static methods you can use if you want content-
based notions of equals and hashCode.

--
email***@***.com
 
 
Patricia Shanahan





PostPosted: 2008-4-10 0:03:00 Top

java-programmer >> hashCode and equals (again) Thomas Fritsch wrote:
...
> (2) When the class principally provides more than 0xFFFFFFF different
> objects. (For example the String class: There is an inifinite number of
> different Strings, but there are only 0xFFFFFFFF different hashCodes)
...

@enable_pedantry

There are 0x100000000 distinct hash code values, 0 through
Integer.MAX_VALUE. This means, for example, that Integer can use its own
int value as hash code.

The finite number of char values, combined with the use of an int to
represent the length of a String, sets a very large but finite limit on
the number of different Strings.

@disable_pedantry

Patricia
 
 
Eric Sosman





PostPosted: 2008-4-10 0:15:00 Top

java-programmer >> hashCode and equals (again) Patricia Shanahan wrote:
> Thomas Fritsch wrote:
> ...
>> (2) When the class principally provides more than 0xFFFFFFF different
>> objects. (For example the String class: There is an inifinite number of
>> different Strings, but there are only 0xFFFFFFFF different hashCodes)
> ...
>
> @enable_pedantry
>
> There are 0x100000000 distinct hash code values, 0 through
> Integer.MAX_VALUE. This means, for example, that Integer can use its own
> int value as hash code.

@enable_nitpick

There are 0x100000000 distinct hash code values, Integer.MIN_VALUE
through Integer.MAX_VALUE.

@disable_nitpick

> @disable_pedantry

--
email***@***.com
 
 
Arved Sandstrom





PostPosted: 2008-4-10 0:30:00 Top

java-programmer >> hashCode and equals (again) "Todd" <email***@***.com> wrote in message
news:email***@***.com...
> Hello,
>
> I have spent a great deal of time reading through the postings in this
> group as well as tutorials/explanations on sites elsewhere (i.e.,
> Roedy's, etc.), but have not been able to get a good grasp of hashCode
> and equals. I understand most of the rules for hashCode are defined
> for use of objects in maps and other comparable collections, so it is
> from that POV that I am trying to get a good grasp of the concepts.
>
> Please help if you can - especially the SCCE later.
>
> 1. Originally, I thought that it made sense to make an equals method
> that uses hashCode as its criteria for equality. However, as I now
> understand hashCode, the code _must_ be the same for equal objects,
> BUT it is _possible_ to be the same for non-equal objects. Am I
> stating this correctly?
>
> 2. When would one use a set of criteria to determine equality that is
> different from the criteria used to generate a hashCode?

Usually you wouldn't. The significant fields that you pick to define
equality are the ones that semantically describe the identity of an object.
Once you've picked those fields for equals(), in order to satisfy the
contracts you'll pick from a subset of those fields to implement hashCode(),
bearing in mind that a set is a subset of itself. Because with a hashCode
you'd like to maximize the variability, it's in your interests to use as
many of the significant fields (used in equals()) as you can.

> 3. Why aren't the hashCode_s in the following code the same?
[ SNIP ]

Use the Arrays.equals() and Arrays.hashCode() methods.

AHS


 
 
Mike Schilling





PostPosted: 2008-4-10 1:03:00 Top

java-programmer >> hashCode and equals (again)
"Patricia Shanahan" <email***@***.com> wrote in message
news:ftipcg$jaj$email***@***.com...
> Thomas Fritsch wrote:
> ...
>> (2) When the class principally provides more than 0xFFFFFFF
>> different
>> objects. (For example the String class: There is an inifinite
>> number of
>> different Strings, but there are only 0xFFFFFFFF different
>> hashCodes)
> ...
>
> @enable_pedantry
>
> There are 0x100000000 distinct hash code values, 0 through
> Integer.MAX_VALUE. This means, for example, that Integer can use its
> own
> int value as hash code.
>
> The finite number of char values, combined with the use of an int to
> represent the length of a String, sets a very large but finite limit
> on
> the number of different Strings.
>
> @disable_pedantry
>
> Patricia


 
 
Roedy Green





PostPosted: 2008-4-10 4:44:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>1. Originally, I thought that it made sense to make an equals method
>that uses hashCode as its criteria for equality. However, as I now
>understand hashCode, the code _must_ be the same for equal objects,
>BUT it is _possible_ to be the same for non-equal objects. Am I
>stating this correctly?

Equal hashCodes in general are not sufficient to ensure Object
equality. However, if the hashCodes are not equal, you know the
Objects can抰 possibly be equal. Consider how many 50-character
Strings there are (65535^50) and how many possible hashCodes there are
(2^32). It should be obvious there are WAY more Strings than
hashCodes. So the same hashCode HAS to be reused over and over for
different Strings.

--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2008-4-10 5:16:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

> Originally, I thought that it made sense to make an equals method
>that uses hashCode as its criteria for equality. However, as I now
>understand hashCode, the code _must_ be the same for equal objects,
>BUT it is _possible_ to be the same for non-equal objects. Am I
>stating this correctly?

Yes. Mathematically this is like a homologous mapping from the set of
Strings to the smaller set of HashCodes. Most of the time you can't
avoid duplicate reuse of the hashcodes.

Perhaps thinking of hashcodes as a generalisation of the % operator
might help. Equal numbers %149 must give the same result, but is also
possible for unequal numbers %149 to give the same result.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2008-4-10 5:18:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>
>2. When would one use a set of criteria to determine equality that is
>different from the criteria used to generate a hashCode?

a fast compare might check for equality of hashcode. If not equal you
know right away the two can't be equal. You then compare the
addresses. If equal, you know the entire objects must be equal (the
same).

Failing that, you check size. If they are not the same you know the
two can't be equal.

Failing that, you do your byte by byte comparison.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2008-4-10 5:26:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>2. When would one use a set of criteria to determine equality that is
>different from the criteria used to generate a hashCode?

Here is a strategy for writing an equals method for some Object:

1. Check for equality of the cached hashcodes. If they are not equal
you know right away the two Objects can抰 be equal.

2. You then compare the two addresses/references. If equal, you know
the entire Objects must be equal (the same).

3. Failing that, you check the Object sizes. If they are not the same
you know the two can抰 be equal.

4. Failing that, you do your byte by byte comparison.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2008-4-10 5:28:00 Top

java-programmer >> hashCode and equals (again) On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

> int[] a = { 1, 7, 0, 0 };
> int[] b = { 1, 7, 0, 0 };
>
> System.out.println( "equals: " + a.equals( b ) );
> System.out.println( "hash a: " + a.hashCode() );
> System.out.println( "hash b: " + b.hashCode() );

See http://mindprod.com/jgloss/hashcode.html

int [] is using the lame default hashCode algorithm for Objects based
on equals defined as ==. It uses something effectively the same as
the Object's address as the hashCode.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Wayne





PostPosted: 2008-4-10 6:01:00 Top

java-programmer >> hashCode and equals (again) Roedy Green wrote:
> On Wed, 9 Apr 2008 07:51:02 -0700 (PDT), Todd
> <email***@***.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> 2. When would one use a set of criteria to determine equality that is
>> different from the criteria used to generate a hashCode?
>
> a fast compare might check for equality of hashcode. If not equal you
> know right away the two can't be equal. You then compare the
> addresses. If equal, you know the entire objects must be equal (the
> same).
>
> Failing that, you check size. If they are not the same you know the
> two can't be equal.
>
> Failing that, you do your byte by byte comparison.

How do you quickly check the size of two objects? And why can't
the sizes be different for equal objects, e.g., some String
in the object not used in equality testing?

-Wayne
 
 
Hal Rosser





PostPosted: 2008-4-10 7:09:00 Top

java-programmer >> hashCode and equals (again)
"Todd" <email***@***.com> wrote in message
news:email***@***.com...
> Hello,
>
> I have spent a great deal of time reading through the postings in this
> group as well as tutorials/explanations on sites elsewhere (i.e.,
> Roedy's, etc.), but have not been able to get a good grasp of hashCode
> and equals. I understand most of the rules for hashCode are defined
> for use of objects in maps and other comparable collections, so it is
> from that POV that I am trying to get a good grasp of the concepts.
>
> Please help if you can - especially the SCCE later.
>
> 1. Originally, I thought that it made sense to make an equals method
> that uses hashCode as its criteria for equality. However, as I now
> understand hashCode, the code _must_ be the same for equal objects,
> BUT it is _possible_ to be the same for non-equal objects. Am I
> stating this correctly?
>
> 2. When would one use a set of criteria to determine equality that is
> different from the criteria used to generate a hashCode?
>
> 3. Why aren't the hashCode_s in the following code the same?

When comparing object, most of the time you don't worry about the hashCode,
When comparing objects, it up to you - the creator of the class - to
determine how objects of the same class are compared.
If you have a class "Customer" - and you create an array of Customer
objects, then lets assume you want to sort that array in ascending order.
Would you expect the array to be sorted in Alphabetical order by Last name -
or by zip code, or by account balance? How do you decide which is larger?
If you implement the Comparable interface and override the compareTo
method - YOU decide in what order the customers should be sorted. You can
use the sort method of the Arrays class to sort that array of objects - but
only if the Customer class implements the Comparable interface. So take a
look at the Comparable interface in the API. The answer to your questions
may be simpler than you had anticipated.
If you want info about hashCode - then Roedy and the others have you
covered. I may have interpreted your post differently.
You can have your equals method use the compareTo method.



 
 
Lew





PostPosted: 2008-4-10 10:20:00 Top

java-programmer >> hashCode and equals (again) Hendrik Maryns wrote:
> Yes. There generally is no need to make your equals() function that
> complex, that it depends on hashCode()

It's generally an outright bad idea to base equals() on hashCode(), not merely
unnecessary.

Todd wrote:
>>> 2. When would one use a set of criteria to determine equality that is
>>> different from the criteria used to generate a hashCode?

If you had bothered to read the Javadocs for hashCode(), you'd have seen:
> The general contract of hashCode is:

> * Whenever it is invoked on the same object more than once during an
> execution of a Java application, the hashCode method must consistently
> return the same integer, provided no information used in equals
> comparisons on the object is modified. This integer need not remain
> consistent from one execution of an application to another execution
> of the same application.

> * If two objects are equal according to the equals(Object) method,
> then calling the hashCode method on each of the two objects must
> produce the same integer result.

> * It is not required that if two objects are unequal according to
> the equals(java.lang.Object) method, then calling the hashCode method
> on each of the two objects must produce distinct integer results.
> However, the programmer should be aware that producing distinct integer
> results for unequal objects may improve the performance of hashtables.

Todd:
>>> 3. Why aren't the hashCode_s in the following code the same?

Hendrik Maryns:
> Arrays are objects. hashCode() for an array is the hashCode of Object,
> which is simply based on its place in memory,

Sort of, but not really. Since objects move around in memory in the JVM,
there's no way that a non-volatile hash code could always represent a "place
in memory" in any meaningful way.

>> Question I forgot:
>> Should the hashCode be used as an equality criteria ~ as long as it is
>> combined with some other criteria?

No, it should not.

> Isn鈥檛 that covered by your first question? I鈥檇 say 鈥榥o鈥?

> Would be perfectly valid, although I would suggest to change hashCode to
> something like
> @Override public int hashCode() {
> return i ^ j;
> }
> Experts will be able to tell you more about how to combine i and j,
> there are some reasons for not using 鈥?鈥?

No there aren't. A typical approach for a 32-bit integer hash is to use:

int hash = i * 31 + j;

with an appropriate narrowing cast if i or j are wider than int. (You can
extend this to /n/ elements by induction.)

Donald Knuth <http://en.wikipedia.org/wiki/Donald_Knuth>,
goes into hashes rather thoroughly in /The Art of Computer Programming/. On
line there's <http://en.wikipedia.org/wiki/Hash_code> and a host of other
googlable references.

--
Lew
 
 
Roedy Green





PostPosted: 2008-4-10 10:22:00 Top

java-programmer >> hashCode and equals (again) On Wed, 09 Apr 2008 18:01:16 -0400, Wayne <email***@***.com>
wrote, quoted or indirectly quoted someone who said :

>How do you quickly check the size of two objects? And why can't
>the sizes be different for equal objects, e.g., some String
>in the object not used in equality testing?

You compare the length of the parts of the object that participate in
the equality.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2008-4-10 10:23:00 Top

java-programmer >> hashCode and equals (again) On Thu, 10 Apr 2008 02:21:37 GMT, Roedy Green
<email***@***.com> wrote, quoted or indirectly quoted
someone who said :

>You compare the length of the parts of the object that participate in
>the equality

there is no method to give to you aggregate length of the object. You
would have to serialise it and measure that -- hardly an efficient
process.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Lew





PostPosted: 2008-4-10 10:48:00 Top

java-programmer >> hashCode and equals (again) Roedy Green wrote:
> int [] is using the lame default hashCode algorithm for Objects based
> on equals defined as ==. It uses something effectively the same as
> the Object's address as the hashCode.

Except that it is not really the address.

--
Lew