0

I was thinking why the hash code is implemented in Object class when its purpose is served only while using collections like HashMap.So should'nt the hashcode be implemented in interfaces implementing Maps.

user3274335
  • 85
  • 7
  • This article have a good explanation of purpose of hashcode mathod, it may solve your doubt. http://www.codenuclear.com/hashcode-method-java/ – Navneet Rabadiya Aug 24 '17 at 04:58
  • 4
    HashMaps contain other objects. It's the hash codes of those objects that matter, not the hash code of the whole map. – ajb Aug 24 '17 at 04:58
  • 1
    Map interface also has hashCode(). Not Sure what you are looking for? – Deepesh kumar Gupta Aug 24 '17 at 04:58
  • i mean when i use hashmap.put(object).Is it wrong to compute the hash code in the hash map class for that object or is it some kind of principle that java developers have followed that we precompute the hash code in the object class – user3274335 Aug 24 '17 at 05:02
  • You need to be able to compute the hash codes of the things you're putting in the map, in order to tell which hash bucket to put them in. Since those things might be Objects, the Object class needs to have a hashCode method. – Dawood ibn Kareem Aug 24 '17 at 05:04
  • How would you expect the map to be able to compute that data? – shmosel Aug 24 '17 at 05:05
  • 1
    Related: https://stackoverflow.com/questions/8113752/why-equals-and-hashcode-were-defined-in-object – shmosel Aug 24 '17 at 05:06
  • By using some hashing techniques it can be done in hashMap class too.The thing that is bugging me is for example We have a parent class which by default extends object and has precomputed hash code which i assume has no purpose until i use some Map data structure and by default HashMap is an object too so i presume it will also override hashcode method. – user3274335 Aug 24 '17 at 05:09
  • *By using some hashing techniques it can be done in hashMap class too.* I'm curious what sort of techniques you have in mind. *by default HashMap is an object too so i presume it will also override hashcode method.* What does that have to do with anything?? – shmosel Aug 24 '17 at 05:13
  • By using some hashing techniques it can be done in hashMap class too-i can use chained addressing. by default HashMap is an object too so i presume it will also override hashcode method-this brings back to the same question that i asked if only maps use hashcode why provide it in object class. – user3274335 Aug 24 '17 at 05:19
  • 1
    Yes, an even more elaborate design would pass a `Hasher` object into the `HashMap` constructor and the whole hashing logic could be externalised. That would suit where the object user (as opposed to implementer) knew that in their application there was a 'better' hash rule because of context. That's more flexibility at the possible expense of performance. But not itself wrong. – Persixty Aug 24 '17 at 07:13

3 Answers3

0

It's not a good idea to say that hashcode implementation is used in Collections only.

In the Java API documentation, the general contract of hashCode is given as:

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

So hashcode has to do only with Object. Collections just get benefits from this feature for their own use cases e.g checking objects having same hashcode, storing objects based on hashcode etc.

Note:- Collections doesn't use hashcode value to sort the objects.
nagendra547
  • 5,672
  • 3
  • 29
  • 43
  • I understood now.It basically follows single responsibility principle.Hash Map's responsibility is to just put the object in the specified address computed by hash code and as everything is object in java.It's better to provide the method in the object class as everything implicitly inherits it – user3274335 Aug 24 '17 at 05:39
  • 2
    `hashCode` has nothing to do with comparing objects. The relative value of two `hashCode`s tells you nothing about the ordering of two objects, or even if they are mutually comparable. – Andy Turner Aug 24 '17 at 05:44
  • Yup just went through the source code.The doc said the following Returns a hash code value for the object. This method is supported for the benefit of hashtables such as those provided by java.util.Hashtable and secondly java does'nt provide its implementation.It is written in c or c++.I saw native keyword in its signature. – user3274335 Aug 24 '17 at 05:52
  • Right @Andy. I mentioned objects comparison in term of checking object hashcode value as equal or not nothing about ordering as such. I have just modified it to make it more clear. – nagendra547 Aug 24 '17 at 05:55
0

hashcode() method is used mainly in case of hash based collections like HashMap and HashSet. The hash code returned by this method is used for calculation of hash index or bucket index.

HashCode function is the necessity of all classes or POJOs or Beans where we need a comparison or check equality.

Let suppose we need to compare two objects irrespective of the Collection API, then there should be a way to achieve it. If HashCode is not the part of Object Class then it would be difficult to calculate the hash every time and be an overburden.

Niranjan Nayak
  • 89
  • 2
0

It's a pragmatic design decision but the question is essentially correct. A purist analysis would say that it's an example of a Interface Bloat or a Fat Interface. The Java java.lang.Object has more methods than are strictly required by (or even meaningful for) all objects. It's not just hashCode() either.

It's arguable that the only method on Object that makes sense for all objects is getClass().

Not all applications are concurrent let alone needing their own monitors. So a purist object model would remove notify(), notifyAll() and 3 versions of wait() to an interface called (say) Monitored and then only permit synchronized to be used with objects implementing that.

It's very common for it to be either invalid or unnecessary to clone() objects - though that method is fortunately protected. Again best off in an interface say interface Cloneable<T>.

Object identity comparisons (are these references to the same object) has been provided as the intrinsic operator ==, so equals(Object) should (still being a purist) be in a ValueComparable<T> interface for objects that have that semantic (many don't). Being very pure even then you'd push hashCode() into another interface (say) HashCodable.

finalize() could also be put in an interface HasFinalize. Indeed that could make the garbage collectors life a bit easier especially given its use so rare and specialized.

However there is a clear design decision in Java to simplify things and the designers decided to put a number of methods in Object that are apparently 'frequently used' or useful rather than 'strictly part of the minimal nature of being an object' which is (in the Java model at least) 'being an instance of some class of objects (having common methods, interfaces and semantics)'.

IMHO hashCode() is probably the least out of place! It is totally unnecessary to provide a monitor on every object and leaves implementers with a headache of supporting the methods on every object knowing they will be called for a minuscule number of them. Don't under estimate the overhead that might cause given it may be necessary to allocate things like mutexes a whole cache-line (typically tens of bytes) to every one of millions of objects and there being no sane way it would ever get used.

I'm not suggesting for a second 'Java is broken' or 'badly designed'. I am not here to knock Java. It is a great language. As with the design of generics it has always chosen to make things simple and been willing to make some compromises on performance for simplicity and as a result produced a very powerful and accessible language in which by great implementation those performance overheads only occasionally grate.

But to repeat the point I think we should recognise those methods are not in the intrinsic nature of all objects.

Persixty
  • 8,165
  • 2
  • 13
  • 35