Will my object creation fail with improper hashcode-equals implementation?

I want to create a class Customer who can be uniquely identified by Customer No.

I wrote the code below

public class Customer{
private Integer customerNo;
private String customerName;
public Customer(Integer customerNo, String customerName){
this.customerNo = customerNo;
this.customerName = customerName;
}
@Override
public int hashCode(){
return this.customerNo;
}
public Integer getCustomerNo(){
return this.customerNo;
}
public String getCustomerName(){
return this.customerName;
}
@Override
public boolean equals(Object o){
Customer cus = (Customer) o;
return (this.customerNo == cus.getCustomerNo() && this.customerName != null && this.customerName.equals(cus.getCustomerName()));
}
@Override
public String toString(){
StringBuffer strb = new StringBuffer();
strb.append("Customer No ")
.append(this.customerNo)
.append(", Customer Name ")
.append(this.customerName)
.append("\n");
return strb.toString();	
}    	
public static void main(String [] args){
Set<Customer> set = null;
try{
set = new HashSet<Customer>();
set.add(new Customer(1,"Jack"));
set.add(new Customer(3,"Will"));
set.add(new Customer(1,"Tom"));
set.add(new Customer(3,"Fill"));
System.out.println("Size "+set.size());
}catch(Exception e){
e.printStackTrace();
}
}
}

From the above code you can see that I am returning my hashcode as customer No.

And my equality is also based on customer No. and Customer Name

If I run the above code the output will be

D:\Java_Projects>java Customer
Size 4
D:\Java_Projects>

The output is 4 objects getting created of same customer No.
The reason is even though the customer no. is same, but the names are different,
as per my above implementation of 'equals' its based on both customerNo and customer Name.
As 4 different combinations of CustomerNo-CustomerName, hence 4 objects getting created.

My question is,

Is my above hashcode implementation a bad practise ?

What all failures I can come accross ?

What if I create 500,000 Customer objects with same customer No, what will happen ?

Whether there will be 500,000 customer objects placed in a same bucket No ?

There is an implicit contract beteween equals(...) and hashCode():

> The general contract of hashCode is:
>
> - 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.
>
> - 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.
>
> - 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 hash tables.

Your implementation satisfies all three constraints. However, best practice is that all attributes that are compared in equals(...) should also influence hashCode() and vice-versa. Otherwise, it might be possible that data structures using hashCode() (e.g. HahsMap and HashSet) can perform sub-optimally. One reason is, as you mentioned, that all objects with the same hashCode are placed in the same bucket and thus the accesss may not have constant time complexity.

This will not, however, result in exceptions being thrown.

> Is my above hashcode implementation a bad practise ?

Assuming different customers have different customerNo most of the time, this is a good implementation. In a real world application, customerNo would most likely be a unique identifier, with uniqueness guaranteed by a database constraint.

> What all failures I can come accross ?

You haven't handled the case where customerNo is null. Here's one way to do that:

public int hashCode(){
return Objects.hash(customerNo);
}

This will return 0 when customerNo is null.

You have another bug in the equals method: Integer objects should not be compared with ==, it will give you unexpected results. Also, two customers with customerName set to null are never equal. The Objects.equals method solves these problems.

return Objects.equals(this.customerNo, cus.customerNo) 
&& Objects.equals(this.customerName, cus.customerName);

> What if I create 500,000 Customer objects with same customer No, what will happen ?
> Whether there will be 500,000 customer objects placed in a same bucket No ?

In this scenario, all objects will indeed be placed in the same bucket. Your HashSet is reduced to a linked list data structure, and it will perform poorly: to locate a customer object, the data structure has to compare the given object with every object in the worst case.

If Customer implemented Comparable, the hash table bucket could use a binary search tree instead of a linked list, and the performance would not be impacted as badly.