Hashcode and equals contract in java

You must override hashCode in every class that overrides equals. If you fail to do so, your class will violate the general contract for hashCode, which will prevent it from functioning properly in collections such as HashMap and HashSet. Here is the contract, adapted from the Object specification :

• When the hashCode method is invoked on an object repeatedly during an execution of an application, it must consistently return the same value, provided no information used in equals comparisons is modified. 
This value need not remain consistent from one execution of an application to another. 

• If two objects are equal according to the equals(Object) method, then calling hashCode on the two objects must produce the same integer result. 

• If two objects are unequal according to the equals(Object) method, it is not required that calling hashCode on each of the objects must produce distinct results. However, the programmer should be aware that producing distinct results for unequal objects may improve the performance of hash tables. The key provision that is violated when you fail to override hashCode is the second one: equal objects must have equal hash codes. Two distinct instances may be logically equal according to a class’s equals method, but to Object’s hashCode method, they’re just two objects with nothing much in common. Therefore, Object’s hashCode method returns two seemingly random numbers instead of two equal numbers as required by the contract.
 For example, suppose you attempt to use instances of the PhoneNumber class from Item 10 as keys in a HashMap:

Map<PhoneNumber, String> m = new HashMap<>(); 
m.put(new PhoneNumber(707, 867, 5309), "Jenny"); 
At this point, you might expect 
m.get(new PhoneNumber(707, 867, 5309)) to return "Jenny", but instead, it returns null. 

Notice that two PhoneNumber instances are involved: one is used for insertion into the HashMap, and a second, equal instance is used for (attempted) retrieval. The PhoneNumber class’s failure to override hashCode causes the two equal instances to have unequal hash codes, in violation of the hashCode contract. 
Therefore, the get method is likely to look for the phone number in a different hash bucket from the one in which it was stored by the put method. Even if the two instances happen to hash to the same bucket, the get method will almost certainly return null, because HashMap has an optimization that caches the hash code associated with each entry and doesn’t bother checking for object equality if the hash codes don’t match.
Find the below hashcode method example:

@Override
public int hashCode() { 
 int result = Short.hashCode(areaCode); 
result = 31 * result + Short.hashCode(prefix); 
result = 31 * result + Short.hashCode(lineNum);
 return result;
}