This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

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

 
Ranch Hand
Posts: 232
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 6039
58
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 65039
247
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 3407
149
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 232
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 65039
247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a pleasure You can probably find out implementation details if you download the code for openJDK.
 
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 6039
58
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 65039
247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 65039
247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 65039
247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mentioned in despatches?

Congratulations For starting a thread quoted in the July 2019 CodeRanch Journal, you have been awarded a cow.
 
Humans and their filthy friendship brings nothing but trouble. My only solace is this tiny ad:
Java Code Review and Psychology
https://coderanch.com/t/714798/java/Java-Code-Review-Psychology
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!