Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > hashCode

Reply
Thread Tools

hashCode

 
 
bob smith
Guest
Posts: n/a
 
      08-10-2012
From: bob smith <(E-Mail Removed)>

Is it always technically correct to override the hashCode function like so:

@Override
public int hashCode() {
return 1;
}

Would it be potentially better if that was Object's implementation?

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      08-10-2012
To: bob smith
From: Arne Vajhoj <(E-Mail Removed)>

On 8/10/2012 11:47 AM, bob smith wrote:
> Is it always technically correct to override the hashCode function like so:
>
> @Override
> public int hashCode() {
> return 1;
> }


It meets the minimum contractual obligation for that method.

But performance of anything using the hash capability (like HashMap<>) would be
very bad.

> Would it be potentially better if that was Object's implementation?


It has a different behavior that may not be valid if you override equals.

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-10-2012
To: bob smith
From: Eric Sosman <(E-Mail Removed)>

On 8/10/2012 11:47 AM, bob smith wrote:
> Is it always technically correct to override the hashCode function like so:
>
> @Override
> public int hashCode() {
> return 1;
> }
>
> Would it be potentially better if that was Object's implementation?


Define "better."

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      08-10-2012
To: Arne Vajh°j
From: markspace <-@.>

On 8/10/2012 9:13 AM, Arne Vajhoj wrote:
> On 8/10/2012 11:47 AM, bob smith wrote:
>> Is it always technically correct to override the hashCode function
>> like so:
>>
>> @Override
>> public int hashCode() {
>> return 1;
>> }

>
> It meets the minimum contractual obligation for that method.
>
> But performance of anything using the hash capability (like HashMap<>)
> would be very bad.
>
>> Would it be potentially better if that was Object's implementation?

>
> It has a different behavior that may not be valid if you override equals.



I think at this point we are doing Bob's homework for him.

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      08-10-2012
To: markspace
From: Arne Vajhoj <(E-Mail Removed)>

On 8/10/2012 1:13 PM, markspace wrote:
> On 8/10/2012 9:13 AM, Arne Vajhoj wrote:
>> On 8/10/2012 11:47 AM, bob smith wrote:
>>> Is it always technically correct to override the hashCode function
>>> like so:
>>>
>>> @Override
>>> public int hashCode() {
>>> return 1;
>>> }

>>
>> It meets the minimum contractual obligation for that method.
>>
>> But performance of anything using the hash capability (like HashMap<>)
>> would be very bad.
>>
>>> Would it be potentially better if that was Object's implementation?

>>
>> It has a different behavior that may not be valid if you override equals.

>
> I think at this point we are doing Bob's homework for him.


Could be.

But I think the question whether returning a constant from hashCode is a valid
Java question for understanding the contract for that method.

And I am pretty sure that I have seen other similar examples (just with 42 as
constant).

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-11-2012
To: bob smith
From: Roedy Green <(E-Mail Removed)>

On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone
who said :

> @Override
> public int hashCode() {
> return 1;
> }


that's about the worst possible hashCode function.

See http://mindprod.com/jgloss/hashcode.html for tips on how to write good
ones.
--
Roedy Green Canadian Mind Products http://mindprod.com A new scientific truth
does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up
that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-11-2012
To: Roedy Green
From: Lew <(E-Mail Removed)>

Roedy Green wrote:
> bob smith wrote, quoted or indirectly quoted someone
> who said :
>
>> @Override
> > public int hashCode() {
> > return 1;
> > }

>
> that's about the worst possible hashCode function.


Normally that's correct, but it's conceivable that one might do it for some
hackish reason. In most situations where one might do such an override as this,
one would do better not to override hashCode().

> See http://mindprod.com/jgloss/hashcode.html for tips on how to write
> good ones.


The default of assembling it via the mix-in of attribute hash codes using the
Knuth constants is usually good enough.

h(object) = Sum(i rnn 0.. n-1) of ( attribute[i] * pow(31, n - 1 - i) );

or

public static int calculateHash(Foo arg) {
int h = 0;

for ( each attribute of Foo that contributes to 'equals()' )
{
h = 31 * h + attribute.hashCode();
}
return h;
}

http://en.wikipedia.org/wiki/Hash_function
http://en.wikipedia.org/wiki/Java_hashCode()
http://en.wikipedia.org/wiki/Java_hashCode()#Java

--
Lew

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
bob smith
Guest
Posts: n/a
 
      08-11-2012
To: Eric Sosman
From: bob smith <(E-Mail Removed)>

On Friday, August 10, 2012 11:34:28 AM UTC-5, Eric Sosman wrote:
> On 8/10/2012 11:47 AM, bob smith wrote:
>
> > Is it always technically correct to override the hashCode function like so:

>
> >

>
> > @Override

>
> > public int hashCode() {

>
> > return 1;

>
> > }

>
> >

>
> > Would it be potentially better if that was Object's implementation?

>
>
>
> Define "better."
>
>
>
> --
>
> Eric Sosman
>
> (E-Mail Removed)d


Better in the sense that you would never HAVE to override hashCode.

Now, there are cases where you HAVE to override it, or your code is very
broken.

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-11-2012
To: bob smith
From: Lew <(E-Mail Removed)>

bob smith wrote:
> Eric Sosman wrote:
>> bob smith wrote:
>>> Is it always technically correct to override the hashCode function like so:


It complies with the contract for 'hashCode()'. Is that all it takes to be
correct?

>>> Would it be potentially better if that was Object's implementation?


Would what be better if what were Object's implementation of what?

>> Define "better."


> Better in the sense that you would never HAVE to override hashCode.
>
> Now, there are cases where you HAVE to override it, or your code is very

broken.

No.

No matter what 'Object''s 'hashCode()' implementation were, it would need to be
overridden when you want value equality instead of object identity for
'equals()'.

See Joshua Bloch's seminal work /Effective Java/, which has items that pertain
to this.

Bottom line: 'hashCode()', 'equals()', and when present, 'compareTo()' must be
consistent.

'toString()' should be consistent with those.

As long as 'hashCode()' fulfills the contract, your code will work -
functionally. But a bad
'hashCode()' could and likely will noticeably affect performance. There is more
to correctness
than mere functional conformance.

--
Lew

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      08-11-2012
To: Roedy Green
From: Arne Vajhoj <(E-Mail Removed)>

On 8/10/2012 3:17 PM, Roedy Green wrote:
> On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
> <(E-Mail Removed)> wrote, quoted or indirectly quoted someone
> who said :
>
>> @Override
>> public int hashCode() {
>> return 1;
>> }

>
> that's about the worst possible hashCode function.


Yes, but the posted asked "Is it always technically correct to ..." not whether
is was "best possible".

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hashcode of primitive types Dimitri Pissarenko Java 5 01-29-2004 11:05 PM
Improving hashCode() to match equals() Marco Java 10 01-17-2004 09:55 PM
Designing hashCode() methods kelvSYC Java 1 12-24-2003 02:56 AM
equals and hashCode Gregory A. Swarthout Java 2 12-20-2003 12:34 AM
hashCode for byte[] Roedy Green Java 1 08-22-2003 02:08 AM



Advertisments