does hash-code of an object represent its memory address?

[Arun Singh Raaj]

if hash-code of an object represents its memory address then why two different objects with same hash-code don't result 'true' when performed == on them?

[Carey Brown]

A hash code IS  NOT an address. Two objects with the same hash code MAY be equal but may not. A hash code is often used to test to see if it is potentially equal with the presumption that using equals() is more expensive in terms of CPU cycles. Collections like HashMap have to take into account and deal with objects with the same hash values that are not actually equal.

[Campbell Ritchie]

To answer the question in the thread title:- No.

If you find older versions of the API, even as recent as Java8, it used to say that Object#hashCode typically (not always) derived the hash code from the address, but Java10 is intentionally evasive:-

The Java10 API wrote:The hashCode may or may not be implemented as some function of an object's memory address at some point in time.

And by Java12, they stopped saying anything about memory location at all. But people still learn that the hash code represents its memory address, which has never actually been true. Did a teacher tell you that, or did you read it in some book or other?
If you go back to the Java12 link, you will see it is necessary to override the hashCode() method(←same link repeated) whenever you override equals(). The idea of overriding equals() is to provide a definiton of when two distinct objects (i.e.objects for which ob1 == ob1 returns false) to return true from equals(). If two object references are regarded as equal, they must produce the same hash code without both references having to point to the same object. That requirement has gone back to Java1.0, so it has never actually been true that a hash code represents a memory location.

[Piet Souris]

Another reason why it is very unlikely for a hashCode to represent a memory address, is that that hashCode is an int.

[Arun Singh Raaj]

Thanks for the info.
The default implementation of hashCode() in Object class is possibly unknown, but definitely it's not memory-address representation.  

[Campbell Ritchie]

That's a pleasure You can probably find out implementation details if you download the code for openJDK.

[Tim Holloway]

The default hashCode() value could be any unique value. When not overridden, the JVM can synthesize whatever value it wants, including absolute memory address of the object, "handle" address of the object (MacIntosh programmers will understand this one), or even the sequence number that the object came from the factory with. It is. in short, meaningless except for the purposes of establishing an identity.

In certain cases, such as cached items, the "same" object may not be the same actual object. That is, "equals()" could be true when "==" is not. In such cases, the two "same" objects must return the same value from hashCode(). Many times, this hash value is computed from key object property values via one of several popular hash-computation algorithms.

[Carey Brown]

Tim Holloway wrote:The default hashCode() value could be any unique value.

The value could be unique, but the likely hood is not guaranteed and can even be quite repetitive depending on the hashing algorithm and the data being hashed. As an extreme example, there's nothing preventing an implementation of hashCode() from always returning '1'. In the end there are only so many unique integer values.

[Tim Holloway]

Carey Brown wrote:

Tim Holloway wrote:The default hashCode() value could be any unique value.

The value could be unique, but the likely hood is not guaranteed and can even be quite repetitive depending on the hashing algorithm and the data being hashed. As an extreme example, there's nothing preventing an implementation of hashCode() from always returning '1'. In the end there are only so many unique integer values.

Ah yes, that's the very definition of "hash". On the other hand, a Perfect Hash is one where every item has a unique hash value and there aren't any unused values. A Perfect Hash makes an ideal (optimal) hash table.

Of course, there are - mathematically speaking - actually an infinite number of integer values. But of course, what we mean here is Java integers, whose range is a mere 4 billion or so.

[Campbell Ritchie]

With the exception of a few types where there is a bijective (one‑to‑one) relationship between the value and its hash code (e.g. Integer), is a perfect hash ever going to be feasible to implement?

[Tim Holloway]

Campbell Ritchie wrote:With the exception of a few types where there is a bijective (one‑to‑one) relationship between the value and its hash code (e.g. Integer), is a perfect hash ever going to be feasible to implement?

There's been a lot of work done on ways to make a perfect hash. In ancient (mainframe-era) times, a 32K machine would have been respectable, and a perfect hash would have been very desirable. I think I may have a few antique issues of Computer Language and/or Dr. Dobbs Journal magazine on the topic. And doubtless you could cruise the archives of the Association for Computing Machinery.

Even today, having a hash with no overflows is added performance, and if you can have optimal memory usage to boot, so much the better. In that's just in-memory hashes. Hash indexes have been popular for persistent storage for decades.

That's why the Java hash classes are so tunable.

[Campbell Ritchie]

Tim Holloway wrote:. . . a hash with no overflows . . ..

Does that mean no overflows whilst calculating the hash? How do you achieve that? Except for the case of things like Integer which I mentioned earlier.

[Tim Holloway]

With a Perfect Hash, every item that will go into the hash has a unique hash code. Hash overflows occur when hash codes are not unique and more than one item with that hash code is added to the hash. Commonly, the overflow is simply chained to the first entry for that hash and so on, forming a linear singly-linked list, so a very imperfect hash can have serious performance issues, especially if you're using it for something like a database index.

A Perfect Hash is most attainable when the hash table is immutable, filled with known elements. A zero-overflow hash is about as good as you can expect when this isn't possible - zero-overflow would have the potential for empty hash cells, but no overflows, so space usage isn't 100% efficient but performance is. Making a hash zero-overflow (or at least nearly so) means knowing what types of data will be stored and tuning your hashing algorithm accordingly.

[Campbell Ritchie]

Mentioned in despatches?

Congratulations For starting a thread quoted in the July 2019 CodeRanch Journal, you have been awarded a cow.