Re: hashCode

Discussion in 'Java' started by Lew, Aug 13, 2012.

  1. Lew

    Lew Guest

    To: Arne Vajhøj
    From: "Lew" <lew@1:261/38.remove-nlb-this>

    To: Arne Vajhoj
    From: "Lew" <lew@1:261/38.remove-m2z-this>

    To: Arne Vajhoj
    From: Lew <>

    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

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

    --- 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
    Lew, Aug 13, 2012
    #1
    1. Advertising

  2. To: Lew
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-nlb-this>

    To: Lew
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-m2z-this>

    To: Lew
    From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <>

    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

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

    --- 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
    Arne Vajhøj, Aug 13, 2012
    #2
    1. Advertising

  3. To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-nlb-this>

    To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-m2z-this>

    To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <>

    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

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

    --- 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
    Arne Vajhøj, Aug 13, 2012
    #3
  4. Lew

    Eric Sosman Guest

    To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: "Eric Sosman" <eric.sosman@1:261/38.remove-nlb-this>

    To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: "Eric Sosman" <eric.sosman@1:261/38.remove-m2z-this>

    To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
    From: Eric Sosman <>

    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
    d

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

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

    --- 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
    Eric Sosman, Aug 13, 2012
    #4
  5. To: Eric Sosman
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-nlb-this>

    To: Eric Sosman
    From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
    ove-m2z-this>

    To: Eric Sosman
    From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <>

    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

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

    --- 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
    Arne Vajhøj, Aug 13, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green

    hashCode for byte[]

    Roedy Green, Aug 22, 2003, in forum: Java
    Replies:
    1
    Views:
    418
    Dale King
    Aug 22, 2003
  2. Marco
    Replies:
    10
    Views:
    763
  3. Gregory A. Swarthout

    equals and hashCode

    Gregory A. Swarthout, Dec 19, 2003, in forum: Java
    Replies:
    2
    Views:
    347
    Silvio Bierman
    Dec 20, 2003
  4. kelvSYC

    Designing hashCode() methods

    kelvSYC, Dec 23, 2003, in forum: Java
    Replies:
    1
    Views:
    369
    Ulrich Stern
    Dec 24, 2003
  5. Dimitri Pissarenko

    Hashcode of primitive types

    Dimitri Pissarenko, Jan 29, 2004, in forum: Java
    Replies:
    5
    Views:
    5,831
    Hylander
    Jan 29, 2004
Loading...

Share This Page