Java Hashing – Why Use `equals` if `hashcode` is Already Implemented?

hashingjava

I got a question about why we need equals if we have hashcode.

My first attempt was the answer because collision. But we corrected starting point with the assumption that we have not many objects so there is no collision at all.

My second attempt was the answer because of the speed. But I also got the reply that there is something conceptual difference between hashcode and equals.

So I read a lot of posts, the java doc and can not find the answer. Do I miss something?

Best Answer

To put it bluntly: they serve different purposes.

Equals is for testing equality.
Hashcode is in order to produce an int (hopefully well distributed)

if your hashcode is unique, you could as well use it for equality. However, for many kind of objects, producing such a unique hash is plainly impossible.

Imagine an object containing two ints a and b. There is no way to produce a unique int hash for such an object. So you still need equality to compare them.

As for the comparator, it's usually a bad idea to use the output as hash because the result is not well distributed, resulting in lots of collisions when used in hash maps or similar data structures.

Related Solutions

Java – Is Object Pooling a Deprecated Technique?

It is deprecated as a general technique, because - as you noticed - creation and destruction of short lived objects per se (i.e. memory allocation and GC) is extremely cheap in modern JVMs. So using a hand-written object pool for your run-of-the-mill objects is most likely slower, more complicated and more error-prone than plain new.*

It still has its uses though, for special objects whose creation is relatively costly, like DB / network connections, threads etc.

*_{Once I had to improve the performance of a crawling Java app. Investigation uncovered an attempt to use an object pool to allocate millions of objects... and the clever guy who wrote it used a single global lock to make it thread safe. Replacing the pool with plain new made the app 30 times faster.}

Java Generics – Using Raw Types in Method Signatures

Yes, you are. Generic wildcards enforce that the container contains "something, but we're not sure what" and raw types are just "the container contains objects".

So you can get some counterintuitive results,

List<?> wild = new ArrayList<String>();
List    raw  = new ArrayList<String>();
wild.add(1); // Compile time error
raw.add(1);
raw.add("Foo");
wild.add("string"); // Still a compile time error

Wild cards are represented as the same as raw at run time, but they are typechecked to make sure you never do something silly, like adding random objects to it.

So if you don't care about type safety, then yes, you can go ahead and use List, but for 3 characters, I'd just use the parameterized type.

Best Answer

Related Solutions

Java – Is Object Pooling a Deprecated Technique?

Java Generics – Using Raw Types in Method Signatures

Related Topic