Tuesday, January 24, 2012

equals() and hashCode() methods of Object Class

HashTable, HashMap and HashSet are the Collection classes in java.util package that make use of hashing algorithm to store objects. In all these Collection classes except HashSet, objects are stored as key-value pairs. For the storage and the retrieval of any user-defined objects it is a good practice to override the following methods which is mentioned below,
  • hashCode()
  • equals()
These methods are available in the Object class and hence available to all java classes.Using these two methods, an object can be stored or retrieved from a Hashtable, HashMap or HashSet.
hashCode() method
This method returns a hashcode value as an int for the object. Default implementation for hashcode() should be overridden in order to make searching of data faster. The implementation of hashCode() method for an user-defined object should be calculated based on the properties of the class which we wish to consider.
equals() method
This method returns a boolean which specifies whether two objects are equal or not. The default implementation of equals() method given by the Object Class uses the '==' operator to compare two object references, and returns true only if they refer to the same object. But, we can meaningfully re-define this equals() method to have en equality check based on our own criterias.
Consider the following code, which defines two user defined classes Employee and EmployeeId which are supposed to be stored in a Map.
Employee.java

public class Employee {
        private String name;

        public Employee(String name){
               this.name = name;
        }

        public String toString(){
        return name;
        }
}
EmployeeId.java

public class EmployeeId {

        private String id;

        public EmployeeId(String id){
               this.id = id;
        }

        public String toString(){
               return id;
        }      
}
The following class makes use of the above classes by storing it in a Map for later retrieval. We are adding Employee objects into the Map keyed with Employee Id.
HashCodeTest.java

public class HashCodeTest {

        public static void main(String[] args) {

               Map employees = new HashMap();

               employees.put(new EmployeeId("111"), new Employee("Johny"));
               employees.put(new EmployeeId("222"), new Employee("Jeny")); // Line A
               employees.put(new EmployeeId("333"), new Employee("Jessie"));

               Employee emp =  employees.get(new EmployeeId("222")); // Line B
               System.out.println(emp); // Line C
        }
}
In Line B, we try to retrieve the Employee object who has Employee Id with a value of 222. We expect the output to be 'Jeny', because the Employee with Employee Id (222) was already there in the Collection, but surprisingly, the output of the above code is null. The reason is that we did not override the equals() method for EmployeeId and Employee classes because the default implementation of equals() in the Object class considers the new EmployeeId("222") in the put statement and new EmployeeId("222") in the get statement as two different instances, and hence the call to get() in Line B returns null.
Let us look at how the same code works when we provide our desired implementation for hashcode() and equals() methods. We basically override hashcode() here just to make the object to be searched fast.
Employee.java

public class Employee {

        private String name;

        public Employee(String name){
               this.name = name;
        }

        public String toString(){
               return name;
        }

        @Override
        public boolean equals(Object obj){

               if(obj == null) {
                       return false;
               }
               if(obj.getClass() != getClass()){
                       return false;
               }

                Employee emp = (Employee)obj;
               if(this.name == emp.name){
                       return true;
               }
               return false;
        }

        @Override
        public int hashCode(){
               return name.hashCode();
        }
}
EmployeeId.java

public class EmployeeId {

        private String id;

        public EmployeeId(String id){
               this.id = id;
        }

        public String toString(){
               return id;
        }      

        public boolean equals(Object obj){

        if(obj == null)
               return false;

        if(obj.getClass() != getClass()){
               return false;
        }

        EmployeeId empId = (EmployeeId)obj;
        if(this.id == empId.id){
               return true;
        }
        return false;
        }

        @Override
        public int hashCode(){
               return id.hashCode();
        }
}
Now, we get the desired output 'Jeny', because as per our implementation for the equals() method, the new EmployeeId("222") in the put statement and new EmployeeId("222") in the get statement are considered one and the same.

Monday, January 16, 2012

Introduction to RESTful Web Services

REST is a “Representational state transfer” and it is firstly introduced by Roy Fielding (Fielding is one of the principal authors of the HTTP specification and a co-founder of the Apache HTTP Server project) in his 2000 doctoral dissertation.

REST-style services (i.e., RESTful services) adhere to a set of constraints and architectural principles that include the following:
  1.  RESTful services are stateless. As Fielding writes in Section 5.1.3 of his thesis, “each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.”
  2. RESTful services have a uniform interface. This constraint is usually taken to mean that the only allowed operations are the HTTP operations: GET, POST, PUT, and DELETE.
  3. REST-based architectures are built from resources (pieces of information) that are uniquely identified by URIs. For example, in a RESTful purchasing system, each purchase order has a unique URI.
  4. REST components manipulate resources by exchanging representations of the resources. For example, a purchase order resource can be represented by an XML document. Within a RESTful purchasing system, a purchase order might be updated by posting an XML document containing the changed purchase order to its URI