7

I read in a book that hashCode() shows a memory area which helps (e.g. HashSets) to locate appropriate objects in memory. But how can that be true if we cannot manipulate memory in Java directly? There are no pointers, in addition to it objects are created and moved from one place to another and the developer doesn't know about it.

I read that realization like hashCode() {return 42;} is awful and terrible, but what's the difference if we can't instruct VM where to put our objects?

The question is: what is the purpose of hashCode() on deep level if we can't manipulate memory?

Lavekush Agrawal
  • 6,040
  • 7
  • 52
  • 85
gabriel angelos
  • 349
  • 1
  • 9
  • 23
  • 1
    Who said `hashCode` was related to memory location at all? (Sometimes it is, but not necessarily, and it's always preserved even after the object gets moved.) – Louis Wasserman Feb 06 '13 at 17:33
  • 3
    I think your basics of `hashing` are little rusty so i suggest you to first read about `hashing`and this question will be clear to you. – kaysush Feb 06 '13 at 17:34
  • Read this link from wikipedia: http://en.wikipedia.org/wiki/Java_hashCode() – Miguel Prz Feb 06 '13 at 17:34
  • 2
    The hashcode doesn't let the hash table finds the object where it is in memory : it is used as a key (using modulo) to find the object in an array. – Denys Séguret Feb 06 '13 at 17:35
  • 1
    If the book you were reading actually said that, you should throw it away. The `hashCode()` has nothing to do with locating objects in memory. In fact, the hash code is used to create an index for an array,. – Stephen C Feb 06 '13 at 17:43

7 Answers7

9

I read in a book that hashCode() shows a memory area which helps (e.g. HashSets) to locate appropriate objects in memory.

No, that's a completely bogus description of the purpose of hashCode. It's used to find potentially equal objects in an efficient manner. It's got nothing to do with the location of the object in memory.

The idea is that if you've got something like a HashMap, you want to find a matching key quickly when you do a lookup. So you first check the requested key's hash code, and then you can really efficiently find all the keys in your map with that hash code. You can then check each of those (and only those) candidate keys for equality against the requested key.

See the Wikipedia article on hash tables for more information.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
6

I like Jon Skeet's answer (+1) but it requires knowing how hash tables work. A hash table is a data structure, basically an array of buckets, that uses the hashcode of the key to decide which bucket to stick that entry in. That way future calls to retrieve whatever's at that key don't have to sift through the whole list of things stored in the hashtable, the hashtable can calculate the hashcode for the key, then go straight to the matching bucket and look there. The hashcode has to be something that can be calculated quickly, and you'd rather it was unique but if it isn't it's not a disaster, except in the worst case (your return 42;), which is bad because everything ends up in the same bucket and you're back to sifting through everything.

The default value for Object#hashCode may be based on something like a memory location just because it's a convenient sort-of-random number, but as the object is shunted around during memory management that value is cached and nobody cares anyway. The hashcodes created by different objects, like String or BigDecimal, certainly have nothing to do with memory. It's just a number that is quickly generated and that you hope is unique more often than not.

Community
  • 1
  • 1
Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
1

A hash code is a just a "value". It has nothing more to do with "where you put it in memory" than "MyClass obj = new MyClass()" has to do with where "obj" is placed in memory.

So what is a Java hashCode() all about?

Here is a good discussion on the subject:

K&B says that the hashcode() contract are :

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

  2. If two objects are unequal according to the equals(Object) method, there's no requirement about hashcode().

  3. If calling hashcode() on two objects produce different integer result, then both of them must be unequal according to the equals(Object).

paulsm4
  • 114,292
  • 17
  • 138
  • 190
1

A hashcode is a function that takes an object and outputs a numeric value. The hashcode for an object is always the same if the object doesn't change.

Functions like hashmaps that need to store objects, will use a hashcode modulo the size of their internal array to choose in what "memory position" (i.e. array position) to store the object.

There are some cases where collisions may occur (two objects end up with the same hashcode, and that, of course, need to be solved carefully). For the details, I would suggest a read of the wikipedia hashmap entry

Miquel
  • 15,405
  • 8
  • 54
  • 87
0

HashCode is a encryption of an object and with that encryption java knows if the two of the objects for example in collections are the same or different . (SortedSet for an example)

I would recommend you read this article.

Vuk Vasić
  • 1,398
  • 10
  • 27
  • It is not an encryption. An encryption can be decrypted ... and a hash cannot. – Stephen C Feb 06 '13 at 17:41
  • 1
    @Vuk Vasić - but your main point: "that ... java knows if the two of the objects for example in collections are the same or different" is absolutely correct. Thank you for contributing :) – paulsm4 Feb 06 '13 at 17:44
  • md5 is a hash and it can be decrypted and some other hash-es can be descrypted too . So it's the same thing. @paulsm4 it's my pleasure . – Vuk Vasić Feb 06 '13 at 20:06
  • @VukVasić I agree with Stephen C. md5 cannot be "decrypted". It [has vulnerabilities](https://en.wikipedia.org/wiki/MD5), but the express intention of md5, as with any [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) (CHF), is that the hash should be, ideally, impossible to reverse. The purpose of hashCode() is entirely different from the purpose of a CHF. While you *could* use a CHF to generate your hashCode(), it's not [how people do it](http://stackoverflow.com/q/16629893/99717). – Hawkeye Parker Oct 13 '16 at 19:54
0

Yes, it has got nothing to do with the memory address, though it's typically implemented by converting the internal address of the object. The following statement found in the Object's hashCode() method makes it clear that the implementation is not forced to do it.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.

asgs
  • 3,928
  • 6
  • 39
  • 54
0

The hashCode() function takes an object and outputs a numeric value, which doesn't have to be unique. The hashcode for an object is always the same if the object doesn't change.

The value returned by hashCode() is the object's hash code, which is the object's memory address in hexadecimal.

By definition, if two objects are equal, their hash code must also be equal. If you override the equals() method, you change the way two objects are equated and Object's implementation of hashCode() is no longer valid. Therefore, if you override the equals() method, you must also override the hashCode() method as well.

For more, check out this Java hashcode article.

enter image description here

Johnny
  • 14,397
  • 15
  • 77
  • 118