Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #17745
| From | "Arne Vajhøj" <������ høj@1:261/38.remove-m2z-this> |
|---|---|
| Subject | Re: hashCode |
| Message-ID | <5027F2C9.56690.calajapr@time.synchro.net> (permalink) |
| Newsgroups | comp.lang.java.programmer |
| References | <5027F2C7.56685.calajapr@time.synchro.net> |
| Date | 2012-08-12 18:58 +0000 |
| Organization | tds.net |
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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web