Suppose if I want to put a key and its value in a Map.
I believe it is what Java does:
Get the Hashcode of the key and check whether there is a key in the map with the same hashcode.
If there is no key with the same Hashcode then the key can be put into Map.
If there is a key with the same Hashcode then use equals to determine whether the key can be put into Map or not.
My question is why not use == instead of equals in this process?
Doing what you suggest would break the entire concept of equals/hashCode tandem. Both equals and hashCode would be rendered useless and should not even exist.
Java allows the programmer to define the equality sets for his class; if he doesn't want to do it, he can simply opt out of overriding equals and hashCode—and end up with exactly the semantics you propose.
To give a specific example, under your proposal, this would create two separate entries in the map:
Map<Integer, String> map = new HashMap<>();
map.put(10_000, "a");
map.put(10_000, "a");
That is because the literal 10_000 will be autoboxed each time into a new instance of Integer, which, under your semantics, are two separate keys. And then, the statement
System.out.println(map.get(10_000));
would print null, because of course you are using a third key to get. It would in fact be impossible to retrieve any map value by key.
== doesn't really make much sense in from an object oriented sense.
new Integer(3) and new Integer(3) and new Integer(2+1) should all be considered equal. Everything else is really confusing, this is what equals describes. Without this it would be impossible to extract anything from a HashMap() when you don't have the reference to the original key any more. It also would be impossible to look something up in a HashMap using input from a user, when the stuff was put into the HashMap based on the data from a database.
If you are looking for problems around ==,equals and hashCode it is that == should really mean "equals" and referential integrity should have some obscure handle that nobody really knows because you always never use it. Incidentally this is exactly what other languages e.g. Scala do.
Because "==" is used to compare the reference of 2 objects and .equals() the content.One important rule when using Java Collection JFrame is to override the equals method,and also .hashCode() so that if you have 2 objects with the same content to be mapped at the same key(hash code).
If you don't override .enquals ,the method invoked will be than from the Object class which compares the reference with "==".One important detail when you override The .hashCode() is to use final fields.
In java == is used to check reference equality, instead equals() and hashCode() works together as 'single concept' for object equality.
If you need a Map that works with == use IdentityHashMap.
Keys are of object types, and all the classes are dervied from the Object class. If you are using a key of a class written by you and you don't override equals method in your class, what will happen? Here is the answer:
No matter whether two objects of your class has exactly same attribute values but still the result of equals will be false. Just because default equals impelemtations will check whether two objects point to the same memory location or not. This is exactly what == comparision does.
Now coming to the hashMap usage of equals and not ==. This is because when you try to put a key in a map, JVM tries to check whether two objects are equal or not. The only intelligence for JVM to check this equality is by using equals method. And with its default implementation it will do what == comparision will do. But as I mentioned above, if two objects have the same attributes they are actually equal. But sadly == comparision cannot do the attributes comparisions and comes up with true value. And hence overriding the equals method or using the equals method is logically important, while storing the values in a Map.
