Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17644 > unrolled thread

hashCode

Back to article view | Back to comp.lang.java.programmer

Contents

  hashCode "bob smith" <bob.smith@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
    Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
      Re: hashCode "markspace" <markspace@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
        Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
          Re: hashCode "rossum" <rossum@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
    Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
      Re: hashCode "bob smith" <bob.smith@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
            Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
              Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                  Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                    Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Robert Klemme" <robert.klemme@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
              Re: hashCode "Robert Klemme" <robert.klemme@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
                Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-fzq-this> - 2012-08-20 18:58 +0000
                Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-fzq-this> - 2012-08-20 18:58 +0000
        Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Joshua Cranmer" <joshua.cranmer@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
          Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
              Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
            Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
          Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
    Re: hashCode "Roedy Green" <roedy.green@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Lew" <lew@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Roedy Green" <roedy.green@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Joerg Meier" <joerg.meier@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
            Re: hashCode "Mike Winter" <mike.winter@1:261/38.remove-ya-this> - 2012-08-11 19:19 +0000
          Re: hashCode "Peter Duniho" <peter.duniho@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "rossum" <rossum@1:261/38.remove-ya-this> - 2012-08-11 19:19 +0000
      Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
    Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
          Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
      Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
          Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000

Page 1 of 3  [1] 2 3  Next page →

#17644 — hashCode

From: bob smith <bob@coolfone.comze.com>

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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#17645

  To: bob smith
From: Arne Vajhoj <arne@vajhoej.dk>

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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17648

  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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17649

  To: markspace
From: Arne Vajhoj <arne@vajhoej.dk>

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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17702

  To: Arne Vajhøj
From: rossum <rossum48@coldmail.com>

On Fri, 10 Aug 2012 13:38:19 -0400, Arne Vajh-,j <arne@vajhoej.dk> wrote:

>And I am pretty sure that I have seen other similar
>examples (just with 42 as constant).
The magic word is "Bloch".

rossum

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

[toc] | [prev] | [next] | [standalone]

#17647

  To: bob smith
From: Eric Sosman <esosman@ieee-dot-org.invalid>

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
esosman@ieee-dot-org.invalid

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

[toc] | [prev] | [next] | [standalone]

#17691

  To: Eric Sosman
From: bob smith <bob@coolfone.comze.com>

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
>
> esosman@ieee-dot-org.invalid

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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17693

  To: bob smith
From: Lew <lewbloch@gmail.com>

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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17699

  To: Lew
From: Arne Vajhoj <arne@vajhoej.dk>

On 8/10/2012 6:32 PM, Lew wrote:
> bob smith wrote:
>> Now, there are cases where you HAVE to override it, or your code is very
broken.
>
> No.

> 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.

If the code per specs is guaranteed to work then it is correct.

Good (or just decent) performance is not necessary for code to be correct.

At least not in the traditional programming terminology.

In plain English maybe.

Arne

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

[toc] | [prev] | [next] | [standalone]

#17740

  To: Arne Vajhøj
From: Lew <noone@lewscanon.com>

On 08/10/2012 04:30 PM, Arne Vajh-,j wrote:
> On 8/10/2012 6:32 PM, Lew wrote:
>> bob smith wrote:
>>> Now, there are cases where you HAVE to override it, or your code is very
>>> broken.
>>
>> No.
>
>> 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.
>
> If the code per specs is guaranteed to work then it is correct.
>
> Good (or just decent) performance is not necessary for code to
> be correct.
>
> At least not in the traditional programming terminology.
>
> In plain English maybe.

I see your point, but that is not to say that the specs exclude performance 
considerations.

In the case of 'hashCode()', the Javadocs do say, "This method is supported for 
the benefit of hash tables such as those provided by HashMap."
<http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>

The key question here is how you define "benefit". I argue that a hash code 
that is constant does not benefit, say, a 'HashMap' because one of our desired 
uses is constant-order retrieval.

"This implementation provides constant-time performance for the basic 
operations (get and put), assuming the hash function disperses the elements 
properly among the buckets."
<http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html>

Each specification refers to the other. Ergo they are meant to be considered 
together. Taken together, the documentation clearly specifies that "correct" or 
"proper" includes performance considerations. Therefore, by what you say, the 
simple "return 1;" is not correct.

It certainly would not be correct for the 'Object' implementation. "As much as 
is reasonably practical, the hashCode method defined by class Object does 
return distinct integers for distinct objects." [op. cit.]

As you say, Arne, "correct" means it follows the spec. The OP's suggested 
implementation violates the spec on two fronts.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

[toc] | [prev] | [next] | [standalone]

#17745

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 7:24 PM, Lew wrote:
> On 08/10/2012 04:30 PM, Arne Vajh-,j wrote:
>> On 8/10/2012 6:32 PM, Lew wrote:
>>> bob smith wrote:
>>>> Now, there are cases where you HAVE to override it, or your code is
>>>> very
>>>> broken.
>>>
>>> No.
>>
>>> 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.
>>
>> If the code per specs is guaranteed to work then it is correct.
>>
>> Good (or just decent) performance is not necessary for code to
>> be correct.
>>
>> At least not in the traditional programming terminology.
>>
>> In plain English maybe.
>
> I see your point, but that is not to say that the specs exclude
> performance considerations.
>
> In the case of 'hashCode()', the Javadocs do say, "This method is
> supported for the benefit of hash tables such as those provided by
> HashMap."
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>
>
> The key question here is how you define "benefit". I argue that a hash
> code that is constant does not benefit, say, a 'HashMap' because one of
> our desired uses is constant-order retrieval.

Object having the method defined to support effective hashing does not imply 
that it has to it just means that the potential is there.

> "This implementation provides constant-time performance for the basic
> operations (get and put), assuming the hash function disperses the
> elements properly among the buckets."

Yes. And here it makes an assumption. Not that hashCode is implemented correct, 
but that it is implemented in a certain way.

> Each specification refers to the other. Ergo they are meant to be
> considered together. Taken together, the documentation clearly specifies
> that "correct" or "proper" includes performance considerations.
> Therefore, by what you say, the simple "return 1;" is not correct.

> As you say, Arne, "correct" means it follows the spec. The OP's
> suggested implementation violates the spec on two fronts.

No it does not.

It follows exactly the explicit stated contract in the Java doc:

<quote>
  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.
</quote>

The ability to support something does not make it part of the contract.

This is a classic test question in basic Java SE. And that returning a constant 
is correct but not smart should be in most Java SE text books.

Arne

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

[toc] | [prev] | [next] | [standalone]

#17748

  To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 10:15 PM, Arne Vajh-,j wrote:
> This is a classic test question in basic Java SE. And that returning
> a constant is correct but not smart should be in most Java SE
> text books.

Effective Java / Joshua Bloch:

<quote>
// The worst possible legal hash function - never use!
public int hashCode() { return 42; }

It is legal because it ensures that equal objects have the same hash code. It's 
atrocious because ...
</quote>

Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:

<quote>
A hashCode() that returns the same value for all instances whether they're 
equal or not is still a legal - even appropriate - hashCode() method! For 
example,
public int hashCode() {
     return 1492;
}
would not violate the contract
...
This hashCode() method is horrible inefficient, ... ...
Nontheless, this one-hash-fits-all method would be considered appropriate and 
even correct because it doesn't violate the contract. Once more, correct does 
not necessarily mean good.
</quote>

Arne

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

[toc] | [prev] | [next] | [standalone]

#17749

  To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: Eric Sosman <esosman@ieee-dot-org.invalid>

On 8/11/2012 10:29 PM, Arne Vajh-,j wrote:
> On 8/11/2012 10:15 PM, Arne Vajh-,j wrote:
>> This is a classic test question in basic Java SE. And that returning
>> a constant is correct but not smart should be in most Java SE
>> text books.
>
> Effective Java / Joshua Bloch:
>
> <quote>
> // The worst possible legal hash function - never use!
> public int hashCode() { return 42; }
>
> It is legal because it ensures that equal objects have the
> same hash code. It's atrocious because ...
> </quote>
>
> Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:
>
> <quote>
> A hashCode() that returns the same value for all instances whether
> they're equal or not is still a legal - even appropriate - hashCode()
> method! For example,
> public int hashCode() {
>      return 1492;
> }
> would not violate the contract
> ...
> This hashCode() method is horrible inefficient, ...
> ...
> Nontheless, this one-hash-fits-all method would be
> considered appropriate and even correct because it
> doesn't violate the contract. Once more, correct does
> not necessarily mean good.
> </quote>

     All this means is that people know how to describe a "correct"
hashCode(), but nobody knows how to describe a "usable" hashCode() in terms 
that apply testably to all circumstances.

     The O.P. asked whether it would "be potentially better" if
Object's hashCode() returned a constant.  He did *not* ask whether such an 
implementation would be correct; he only asked if it would "be potentially 
better."  Upon prompting he explained what he meant by "better," and in light 
of that explanation the answer to his original question is NO.  Discussions 
about "Oh, but it's CORRECT" are just red herrings; it's still not "better."

--
Eric Sosman
esosman@ieee-dot-org.invalid

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

[toc] | [prev] | [next] | [standalone]

#17752

  To: Eric Sosman
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 10:43 PM, Eric Sosman wrote:
>      The O.P. asked whether it would "be potentially better" if
> Object's hashCode() returned a constant.  He did *not* ask whether
> such an implementation would be correct; he only asked if it would
> "be potentially better."  Upon prompting he explained what he
> meant by "better," and in light of that explanation the answer
> to his original question is NO.  Discussions about "Oh, but it's
> CORRECT" are just red herrings; it's still not "better."


The original questions were:

#Is it always technically correct to override the hashCode function
#like so:
#
#       @Override
#       public int hashCode() {
#               return 1;
#       }

For which the answer is YES. Per documentation.

But with really poor performance in many relevant cases.

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

Which was clarified to:

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

For which the answer is also YES. Per the previous.

But with the same performance note. And a big sigh because it seems to want to 
broaden bad performance from a single class to the entire programming style 
(multiple classes).

Arne

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

[toc] | [prev] | [next] | [standalone]

#17704

  To: bob smith
From: Eric Sosman <esosman@ieee-dot-org.invalid>

On 8/10/2012 6:22 PM, bob smith wrote: [... many blank lines removed for 
legibility's sake ...]
> 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."
>
> 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.

     I cannot think of a case where you HAVE to override hashCode(),
except as a consequence of other choices that you didn't HAVE to make.  You 
don't HAVE to invent classes where distinct instances are considered equal, and 
even if you do you don't HAVE to put those instances in HashMaps or HashSets or 
whatever.

     But that's a bit specious: All it says is that you don't HAVE
to override hashCode() because you don't HAVE to use things that call it.  It's 
like "You don't HAVE to pay taxes, because you don't HAVE to live outside 
prison."  So, let's take it as a given that you will often need to write 
classes that override equals() and hashCode() -- I imagine you understand that 
they go together.

     Okay: Then returning a constant 1 (or 42 or 0 or whatever)
would in fact satisfy the letter of the law regarding hashCode(): Whenever 
x.equals(y) is true, x.hashCode() == y.hashCode().  In your example this would 
be trivially true because x,y,z,... all have the same hashCode() value, whether 
they're equal or not -- You have lived up to the letter of the law.

     Of course, such a hashCode() would make all those hash-based
containers pretty much useless: They would work in the sense that they would 
get the Right Answer, but they'd be abominably slow, with expected performance 
of O(N) instead of O(1).  See
<http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/>
for a survey of some denial-of-service attacks that work by driving hash tables 
from O(1) to O(N), resulting in catastrophic failure of the attacked system.

     In other words, the letter of the law on hashCode() is a bare
minimum that guarantees correct functioning, but it is not enough to guarantee 
usability.  Why isn't the law more specific?  Because nobody knows how to write 
"hashCode() must be correct *and* usable" in terms that would cover all the 
classes all the Java programmers have dreamed up and will dream up.  Your 
hashCode() meets the bare minimum requirement, but is not "usable."  The actual 
hashCode() provided by Object also meets the bare minimum requirement, and *is* 
usable as it stands, until (and unless; you don't HAVE to) you choose to 
implement other equals() semantics, and a hashCode() to match them.


--
Eric Sosman
esosman@ieee-dot-org.invalid

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

[toc] | [prev] | [next] | [standalone]

#17741

  To: Eric Sosman
From: Lew <noone@lewscanon.com>

Eric Sosman wrote:
>      Okay: Then returning a constant 1 (or 42 or 0 or whatever)
> would in fact satisfy the letter of the law regarding hashCode():

Not if you consider all aspects of what the Javadocs promise.

See my post upthread.

> Whenever x.equals(y) is true, x.hashCode() == y.hashCode().  In
> your example this would be trivially true because x,y,z,... all
> have the same hashCode() value, whether they're equal or not --
> You have lived up to the letter of the law.

No, because the law requires that the method support 'HashMap', which in turn 
calls for "properly" hashed objects.

>      Of course, such a hashCode() would make all those hash-based
> containers pretty much useless: They would work in the sense that
> they would get the Right Answer, but they'd be abominably slow,

Indeed.

> with expected performance of O(N) instead of O(1).  See
> <http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/>
> for a survey of some denial-of-service attacks that work by driving
> hash tables from O(1) to O(N), resulting in catastrophic failure
> of the attacked system.
>
>      In other words, the letter of the law on hashCode() is a bare
> minimum that guarantees correct functioning, but it is not enough
> to guarantee usability.  Why isn't the law more specific?  Because

Actually, if you consider all that the Javadocs tell you, this "letter of the 
law" to which you refer is like saying the sequence "ABC" constitutes all of 
"the ABCs".

> nobody knows how to write "hashCode() must be correct *and* usable"
> in terms that would cover all the classes all the Java programmers
> have dreamed up and will dream up.  Your hashCode() meets the bare
> minimum requirement, but is not "usable."  The actual hashCode()
> provided by Object also meets the bare minimum requirement, and *is*
> usable as it stands, until (and unless; you don't HAVE to) you
> choose to implement other equals() semantics, and a hashCode() to
> match them.

As Arne states, "correct" means "fulfills the specification". The specification 
for Java API methods is the standard Javadocs, which do impose performance 
considerations on 'hashCode()'.

One understands that the spec isn't always fully enforceable by the compiler. 
[1] It is correct that the compiler will allow 'return 1;'. It is not correct 
that that fulfills the specification.

[1] Doesn't one?

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

[toc] | [prev] | [next] | [standalone]

#17746

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 7:29 PM, Lew wrote:
> Eric Sosman wrote:
>>      Okay: Then returning a constant 1 (or 42 or 0 or whatever)
>> would in fact satisfy the letter of the law regarding hashCode():
>
> Not if you consider all aspects of what the Javadocs promise.
>
> See my post upthread.
>
>> Whenever x.equals(y) is true, x.hashCode() == y.hashCode().  In
>> your example this would be trivially true because x,y,z,... all
>> have the same hashCode() value, whether they're equal or not --
>> You have lived up to the letter of the law.
>
> No, because the law requires that the method support 'HashMap', which in
> turn calls for "properly" hashed objects.
>
>>      Of course, such a hashCode() would make all those hash-based
>> containers pretty much useless: They would work in the sense that
>> they would get the Right Answer, but they'd be abominably slow,
>
> Indeed.
>
>> with expected performance of O(N) instead of O(1).  See
>> <http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/>
>> for a survey of some denial-of-service attacks that work by driving
>> hash tables from O(1) to O(N), resulting in catastrophic failure
>> of the attacked system.
>>
>>      In other words, the letter of the law on hashCode() is a bare
>> minimum that guarantees correct functioning, but it is not enough
>> to guarantee usability.  Why isn't the law more specific?  Because
>
> Actually, if you consider all that the Javadocs tell you, this "letter
> of the law" to which you refer is like saying the sequence "ABC"
> constitutes all of "the ABCs".
>
>> nobody knows how to write "hashCode() must be correct *and* usable"
>> in terms that would cover all the classes all the Java programmers
>> have dreamed up and will dream up.  Your hashCode() meets the bare
>> minimum requirement, but is not "usable."  The actual hashCode()
>> provided by Object also meets the bare minimum requirement, and *is*
>> usable as it stands, until (and unless; you don't HAVE to) you
>> choose to implement other equals() semantics, and a hashCode() to
>> match them.
>
> As Arne states, "correct" means "fulfills the specification". The
> specification for Java API methods is the standard Javadocs, which do
> impose performance considerations on 'hashCode()'.
>
> One understands that the spec isn't always fully enforceable by the
> compiler. [1] It is correct that the compiler will allow 'return 1;'. It
> is not correct that that fulfills the specification.

It fulfills the spec.

It does not fulfill you bizarre interpretation of "support".

Arne

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

[toc] | [prev] | [next] | [standalone]

#17710

  To: bob smith
From: Arne Vajhoj <arne@vajhoej.dk>

On 8/10/2012 6:22 PM, bob smith wrote:
> 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."
>
> 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.

It is not broken.

It will perform poorly in many cases.

Arne

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

[toc] | [prev] | [next] | [standalone]

#17757

  To: Arne Vajhøj
From: Robert Klemme <shortcutter@googlemail.com>

On 11.08.2012 01:27, Arne Vajhoj wrote:
> On 8/10/2012 6:22 PM, bob smith wrote:
>> 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."
>>
>> 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.
>
> It is not broken.
>
> It will perform poorly in many cases.

Well, I would go as far as to say that it will perform poorly in all cases 
where hashCode() is actually needed - and that makes it broken. The whole idea 
of hashing is based on the fact that the hash code _somehow_ represents the 
item to be hashed.  If all items have the same constant hash code there is no 
point in hashing at all.  So while it does work, it does not work as intended.

Kind regards

        robert

--
remember.guy do |as, often| as.you_can - without end 
http://blog.rubybestpractices.com/

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

[toc] | [prev] | [next] | [standalone]

#17807

  To: Robert Klemme
From: Arne Vajhoj <arne@vajhoej.dk>

On 8/12/2012 11:06 AM, Robert Klemme wrote:
> On 11.08.2012 01:27, Arne Vajhoj wrote:
>> On 8/10/2012 6:22 PM, bob smith wrote:
>>> 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."
>>>
>>> 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.
>>
>> It is not broken.
>>
>> It will perform poorly in many cases.
>
> Well, I would go as far as to say that it will perform poorly in all
> cases where hashCode() is actually needed

More or less.

>                                        - and that makes it broken.

This thread started about whether it is correct. The term correct has a very 
specific meaning in programming and that always return 1 code is correct.

Now you talk about broken. If broken means not good, then you are right. If 
broken means not correct, then you are wrong. I suspect that broken is not very 
well defined.

> The whole idea of hashing is based on the fact that the hash code
> _somehow_ represents the item to be hashed.  If all items have the same
> constant hash code there is no point in hashing at all.  So while it
> does work, it does not work as intended.

It disable the entire hashing functionality and a HashMap get characteristics 
of ArrayList.

But the code should actually work.

Arne

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web