How can we get immutable object if class did not implement cloneable

Question

I have few issues/doubts to fill values in a HashMap

I want a HashMap to accept "Student" as key and "Details" as value. Since key to a hashMap should be immutable I have some doubts how can this be dealt if

1. Student class did not cloneable

2. Student class has reference to which in turn have reference to "Lab"

   public class Student {   
   
       private String id;
       private String name;
       private Department dept;
   
       public Student(String id, String name, Department dept)
       {
         this.id=id;
         this.name=name;
         this.dept=dept;
       }        
   
       public Department getDepartment()
       {
           return this.dept;
       }
   
   }
   
   public class Department {  
   
       private String deptId;
       private Lab lab;
   
       public Department(String deptId, Lab lab)
       {
           this.deptId=deptId;
           this.lab=lab;
       }
   
       public void setLab(Lab lab)
       {
           this.lab=lab;
       }
   }
   
   public class Lab {
   
       private String labId;
       private String labName;
   
       public Lab(String labId, String labName)
       {
           this.labId=labId;
           this.labName=labName;
       }
   
   }
   
   public class StudentDetails
   {
       private String fatherName;
       private String address
   
       public StudentDetails(String fatherName, String address)
       {
       this.fatherName=fatherName;
       this.address=address;
       }
   }
   
   
   public class StudentMaintainer {
   
       public static void main(String[] args)
       {
           StudentDetails stDetails= new StudentDetails("John","Mumbai");
           Lab lab= new Lab("100","CS");
           Department dept= new Department("900", lab);
           Student st = new Student("3000",dept);
   
           Map<Student,StudentDetails> studentMaintainer= new ArrayList<>();
           studentMaintainer.put(st,stDetails);
       }
   }
   

Now Even if Student is cloneable, I can get reference of Department and call setLab() which changes the StudentObject. (Am I wrong?)

Now if Department and Lab are from 3rd party jars, how can I use Student Object in my Map if Student hashCode is (primeNumber+Student.id+Department.id+Lab.id).hashcode() [just some weird case];

Answer 1

Immutability has nothing to do with Cloneable as far as I understand it, and in fact just the opposite. Immutability has more to do with declaring the class final and using immutable fields, non-overridable methods, no setter methods, getter methods that return deep copies of fields or immutable fields, etc... Please read A Strategy for Defining Immutable Objects for more on this.

Also your code has a pseudo-constructor:

public void Student(String id, String name, Department dept)
{
  this.id=id;
  this.name=name;
  this.dept=dept;
}

A true constructor should not be declared to return anything, not even void. Better would be:

// note the difference?
public Student(String id, String name, Department dept)
{
  this.id=id;
  this.name=name;
  this.dept=dept;
}

Also, your Student class should properly override equals and hashCode if it is to work well as a key for a HashMap.

Answer 2

Now Even if Student is cloneable, I can get reference of Department and call setLab() which changes the StudentObject. (Am I wrong?)

You are correct. This can happen, and can cause your Student class to appear to be mutated. For an instance of Student to be immutable, you must not be able to modify any of its fields[0]. That includes calling something like a setter method on one of its fields.

Now if Department and Lab are from 3rd party jars, how can I use Student Object in my Map if Student hashCode is (primeNumber+Student.id+Department.id+Lab.id).hashcode() [just some weird case];

That is a very good question. You obviously can't just change the classes to be immutable, since you don't have control over them, so you may have to get a bit creative. Possible solutions:

• if the third party objects you want to use are interfaces, you could implement the interface with your own type, where the body of every mutator method throws an exception (think e.g. java.util.Collections.unmodfiableList). This has the benefits that you can still refer to the third party class in your codebase, but the drawback that calling mutator methods will fail at runtime, rather than at compile time.

• write adapters in your own codebase, like this:

  public final class MyImmutableDepartment {
      private final MyImmutableLab lab;
      private final String departmentId;
  
      public MyImmutableDepartment(Department thirdPartyMutableDepartment) {
          this.departmentId = thirdPartyMutableDepartment.getId();
          this.lab = new MyImmutableLab(thirdPartyMutableDepartment.getLab());
      }
  
      // getters and the MyImmutableLab class left as an exercise
  }
  

  This has the advantage that you know at compile time, the classes cannot be mutated.

The downside in both approaches is that you basically have to mirror every class from the third party library, to ensure they're immutable.

I don't think there's any other alternatives.

[0] there are some cases where this is possible, and can be used for internal caching, but it's a decent guideline to stick to when learning.

Answer 3

Student does not need to be immutable! Specifically, the requirement is that the behavior of equals/hashCode doesn't change when the key is in the HashMap.

This can be accomplished in three ways:

• Don't implement equals/hashCode. If you use the default reference equality, it doesn't matter how you mutate the key. To clarify intent, override those methods, explicitly call super.equals, and make them final.
• Don't include any fields that will mutate in your calculation of equals/hashCode. Or, if the properties of a field may change but not the reference, use reference equality (==) instead of field.equals() and call System.identityHashCode(field) instead of field.hashCode()
• Don't mutate the object while it is used as a key in the HashMap. A bit dangerous, but works fine if references aren't held by code beyond your control. Document the requirement.

But, in your concrete example, each student has an id. Why would you use any other properties when implementing equals/hashCode.?