Privacy Policy

If you require any more information or have any questions about our privacy policy, please feel free to contact us by email at ashvinbhide@gmail.com.

At www.binary-imaginers.blogspot.com, the privacy of our visitors is of extreme importance to us. This privacy policy document outlines the types of personal information is received and collected by www.binary-imaginers.blogspot.com and how it is used.

Log Files
Like many other Web sites, www.binary-imaginers.blogspot.com makes use of log files. The information inside the log files includes internet protocol ( IP ) addresses, type of browser, Internet Service Provider ( ISP ), date/time stamp, referring/exit pages, and number of clicks to analyze trends, administer the site, track user’s movement around the site, and gather demographic information. IP addresses, and other such information are not linked to any information that is personally identifiable.

Cookies and Web Beacons
www.binary-imaginers.blogspot.com does not use cookies.

DoubleClick DART Cookie
.:: Google, as a third party vendor, uses cookies to serve ads on www.binary-imaginers.blogspot.com.
.:: Google's use of the DART cookie enables it to serve ads to users based on their visit to www.binary-imaginers.blogspot.com and other sites on the Internet.
.:: Users may opt out of the use of the DART cookie by visiting the Google ad and content network privacy policy at the following URL - http://www.google.com/privacy_ads.html

Some of our advertising partners may use cookies and web beacons on our site. Our advertising partners include ....
Google Adsense


These third-party ad servers or ad networks use technology to the advertisements and links that appear on www.binary-imaginers.blogspot.com send directly to your browsers. They automatically receive your IP address when this occurs. Other technologies ( such as cookies, JavaScript, or Web Beacons ) may also be used by the third-party ad networks to measure the effectiveness of their advertisements and / or to personalize the advertising content that you see.

www.binary-imaginers.blogspot.com has no access to or control over these cookies that are used by third-party advertisers.

You should consult the respective privacy policies of these third-party ad servers for more detailed information on their practices as well as for instructions about how to opt-out of certain practices. www.binary-imaginers.blogspot.com's privacy policy does not apply to, and we cannot control the activities of, such other advertisers or web sites.

If you wish to disable cookies, you may do so through your individual browser options. More detailed information about cookie management with specific web browsers can be found at the browsers' respective websites.

java program to count minimum number of bits required to convert a given number into another number

Question: Write a Java program that will return the number of bits that will need to be changed in order to convert an integer, X, into another integer, Y and vice versa.

Explanation: The method should accept two different integers as input. For example, if your method is passed the integers 12 and 16 then your method should return a 3 . 

Let's take a closer look at the example given to us. It says that for the input of a 12 and 16, the output of the method should be a 3. Since we are looking for the number of bits that will need to be changed, let's convert 12 and 16 to binary to further understand this bit manipulation problem. The binary representation of 12 is 01100 and the binary representation of 16 is 10000. Comparing the binary representation of those two numbers, we can see that the first 3 digits are different, which means that to convert 12 to 16 or 16 to 12 we would have to change 3 numbers. And that is why the method that we write should output a 3.

Solution:The binary operator that is perfect for this exercise is the XOR operator. If you need a refresher on how that operator works you can read this: XOR in Java. This is because the XOR operator will return true when the binary digits being compared are different, but will return false when they are the same. So, if we just XOR the two numbers being passed in, the result of the XOR operation will be binary number that will have a binary 1 each and every time there is a different bit between the inputs x and y, and a binary 0 when the bits in the input x and y are the same. So, for example, if we XOR 1001 and 0101 the result of the XOR operation would be a 1100 because the 2 leftmost bits are different, so the result of XOR'ing those 2 bits would be a 1 but the 2 rightmost bits in our inputs are the same, so the result of XOR would be a 0. 

So, the algorithm to solve this bit manipulation interview question would be:

First, XOR the two numbers being passed in - call them x and y - and then call the result Z.

Then, just count the number of binary 1′s in Z since that count represents the number of different bits in the two numbers x and y. In order to count the number of binary 1′s in Z, we can just take Z, and perform the binary AND operation with the number 1. When the result of that operation is a 1 then we know that the very last binary digit in Z is a 1. Then, we can shift Z by 1 bit and repeat until there is nothing left to shift - which is when Z is equal to 0. 

Here is the Java implementation of that algorithm and our final answer to this problem:  

Bit-wise and bit shift operations:

public class BitDiffernce {
    public  int findNumberOfBits(int x, int y) {
        int bitCount = 0;
        int z = x ^ y;  //XOR x and y

        while (z != 0) {
            //increment count if last binary digit is a 1:

            bitCount += z & 1;       
            z = z >> 1;  //shift Z by 1 bit to the right
        }
        return bitCount;
    }

    public static void main(String args[]) {
        BitDiffernce bd = new BitDiffernce();
        System.out.println("No of bits needed to change are: "+
                   bd.findNumberOfBits(12, 46));        
    }
} 

You will get following output:

Output:                                                      
====================================================== 

No of bits needed to change are:2

Bitwise and Bit Shift Operators in Java

This post is all about basic understanding of operators that perform bit-wise and bit shift operations on integral types that Java programming language provides.

Section in this post:

1. List of Operators 
2. Unary bitwise complement 
3. Bitwise AND 
4. Bitwise exclusive OR 
5. Bitwise inclusive OR 
6. Signed left shift 
7. Non circular shift
8. Unsigned right shift(Logical right shift) 
9. Lost Bits are gone 
10. Signed right shift(Arithmetic right shift) 
11. Example

The bitwise operators:

Operator	Name	Example	Result	Description
a & b	and	3 & 5	1	1 if both bits are 1.
a | b	or	3 | 5	7	1 if either bit is 1.
a ^ b	xor	3 ^ 5	6	1 if both bits are different.
~a	not	~3	-4	Inverts the bits.
n << p	left shift	3 <<< 2	12	Shifts the bits of n left p positions. Zero bits are shifted into the low-order positions.
n >> p	right shift	5 >> 2	1	Shifts the bits of n right p positions. If n is a 2's complement signed number, the sign bit is shifted into the high-order positions.
n >>> p	right shift	-4 >>> 28	15	Shifts the bits of n right p positions. Zeros are shifted into the high-order positions.

Note:  "<<<" is not an operator, because it would be redundant. Lets see each operator one by one:

The unary bitwise complement operator:

 

The unary bitwise complement operator "~" inverts a bit pattern; it can be applied to any of the integral types, making every "0" a "1" and every "1" a "0".
 For example: A byte contains 8 bits; applying this operator to a value whose bit pattern is "00000000" would change its pattern to "11111111"

The bitwise & operator:

 

Bitwise AND operator works similar to logical AND operator (&&) and returns 1 if both operands are 1. Difference with bitwise AND and logical AND also known as short-circuit AND operator is that, logical AND operator applies only to boolean type. Also bitwise AND operator is denoted by singe & while short circuit AND operator is denoted by &&. 

For example:If A represent 0010 and B represent 1010 then result of A&B would be 0010.

The bitwise ^ operator:

Bitwise XOR operator is denoted by ^ and also work on individual bits. There is no short-circuit XOR operator in Java and result of bitwise XOR operator is XOR operation of individual bits. see the truth table of XOR operation for predicting result. in short bitwise XOR operators will return 1 if both bits are different and return 0 if both bits are same.

The bitwise | operator:

Bitwise OR operator is also similar to bitwise AND operator and applies to individual bits. It’s different than short-circuit OR operator, which is denoted by (||) and operates on boolean variable. Bitwise OR operator produce result of OR operation on two bits. Like other bitwise operator in Java, bitwise OR is only applicable to integral types.

Left shift (<<)

Integers are stored, in memory, as a series of bits. For example, the number 6 stored as a 32-bit int would be:

00000000 00000000 00000000 00000110

Shifting this bit pattern to the left one position (6 << 1) would result in the number 12:

00000000 00000000 00000000 00001100 

As you can see, the digits have shifted to the left by one position, and the last digit on the right is filled with a zero.

 Note: Shifting left is equivalent to multiplication by powers of 2. So 6 << 1 is equivalent to 6 * 2, and 6 << 3 is equivalent to 6 * 8. A good optimizing compiler will substitute shifts for multiplications when possible.

Non-circular shifting :

 

Please note that these are not circular shifts. Shifting this value to the left by one position (3,758,096,384 << 1):

11100000 00000000 00000000 00000000

results in 3,221,225,472:

11000000 00000000 00000000 00000000

The digit that gets shifted "off the end" is lost. It does not wrap around

Logical right shift (>>>) 

A logical right shift is the converse to the left shift. Rather than moving bits to the left, they simply move to the right. For example, shifting the number 12:

00000000 00000000 00000000 00001100

to the right by one position (12 >>> 1) will get back our original 6:

00000000 00000000 00000000 00000110

So we see that shifting to the right is equivalent to division by powers of 2.

Lost bits are gone

 

However, a shift cannot reclaim "lost" bits. For example, if we shift this pattern:

00111000 00000000 00000000 00000110

to the left 4 positions (939,524,102 << 4), we get 2,147,483,744:

10000000 00000000 00000000 01100000 

and then shifting back ((939,524,102 << 4) >>> 4) we get 134,217,734:

00001000 00000000 00000000 00000110

We cannot get back our original value once we have lost bits.

Arithmetic right shift (>>)

 

The arithmetic right shift is exactly like the logical right shift, except instead of padding with zero, it pads with the most significant bit. This is because the most significant bit is the sign bit, or the bit that distinguishes positive and negative numbers. By padding with the most significant bit, the arithmetic right shift is sign-preserving.

For example, if we interpret this bit pattern as a negative number:

10000000 00000000 00000000 01100000

we have the number -2,147,483,552. Shifting this to the right 4 positions with the arithmetic shift (-2,147,483,552 >> 4) would give us:

11111000 00000000 00000000 00000110

or the number -134,217,722.

So we see that we have preserved the sign of our negative numbers by using the arithmetic right shift, rather than the logical right shift. And once again, we see that we are performing division by powers of 2.

Here a simple java program showing Bit-wise and bit shift operations:

public class tetBitOperator{
 
public static void main(String args[]) {
      int a = 60; /* 60 = 0011 1100 */  
      int b = 13; /* 13 = 0000 1101 */
      int c = 0;

      System.out.println("a="+a);
      System.out.println("b="+b);
      
      c = a & b;       /* 12 = 0000 1100 */ 
      System.out.println("a & b = " + c );

      c = a | b;       /* 61 = 0011 1101 */
      System.out.println("a | b = " + c );

      c = a ^ b;       /* 49 = 0011 0001 */
      System.out.println("a ^ b = " + c );

      c = ~a;          /*-61 = 1100 0011 */
      System.out.println("~a = " + c );

      c = a << 2;     /* 240 = 1111 0000 */
      System.out.println("a << 2 = " + c );

      c = a >> 2;     /* 215 = 1111 */
      System.out.println("a >> 2  = " + c );

      c = a >>> 2;     /* 215 = 0000 1111 */
      System.out.println("a >>> 2 = " + c )
 }
}

Output

==========================================================================

a & b = 12
a | b = 61
a ^ b = 49
~a = -61
a << 2 = 240
a >> 2  = 15
a >>> 2 = 15 

Producer Consumer Problem's solution in Java

From the Wikipedia definition,  the producer–consumer problem (also known as the bounded-buffer problem) is a classic example of a multi-process synchronization problem. The problem describes two processes, the producer and the consumer, who share a common, fixed-size buffer used as a queue. The producer's job is to generate a piece of data, put it into the buffer and start again. At the same time, the consumer is consuming the data (i.e., removing it from the buffer) one piece at a time. The problem is to make sure that the producer won't try to add data into the buffer if it's full and that the consumer won't try to remove data from an empty buffer.

The solution for the producer is to either go to sleep or discard data if the buffer is full. The next time the consumer removes an item from the buffer, it notifies the producer, who starts to fill the buffer again. In the same way, the consumer can go to sleep if it finds the buffer to be empty. The next time the producer puts data into the buffer, it wakes up the sleeping consumer. The solution can be reached by means of inter-process communication. An inadequate solution could result in a deadlock where both processes are waiting to be awakened. The problem can also be generalized to have multiple producers and consumers.

In this post I am sharing my producer-consumer solution written in Java.

Producer class:

import java.util.Vector;

public class MyProducer implements Runnable{
 /*taking vector to use as buffer, 
         *it will keep numbers produced by Producer 
  *and work as synchronisation object
        */
 Vector<Integer> sharedQ;
 // Size will store the maximum size of buffer
 int SIZE;
 /*
  * Constructor for Producer class
  */
 public MyProducer(Vector<Integer> sharedQ, final int size) {
  this.sharedQ =sharedQ;
  this.SIZE= size;
 }
 @Override
 public void run() {
  int i=0;
  while(true){
   i++;
   produce(i);
  }
 }
 /*
  * This method has the logic for producing numbers 
         *and synchronization with consumer
  */
 public void produce(int i) {
  //testing if buffer is already full
  while(sharedQ.size() == SIZE) {
   synchronized (sharedQ) {
    try {
     System.out.println("producer waiting...");
     //waiting until some space is made in buffer
     sharedQ.wait();
    } catch (InterruptedException e) {
     // TODO Auto-generated catch block
     e.printStackTrace();
    }
   }
  }
  //adding numbers in buffer
  synchronized(sharedQ) {
   sharedQ.add(i);
   System.out.println("Producer produced: "+i);
   //notifying other thread which are waiting on sharedQ
   sharedQ.notifyAll();
  }
  try {
   /*
    * making thread to sleep for random time after producing  
    *so as to make output more readable and understandable
    *we can set any arbitrary sleeping time
    */
   Thread.sleep(((long)((Math.random())*10000)));
  } catch (InterruptedException e) {
   e.printStackTrace();
  }
 }
}

Consumer class:

import java.util.Vector;

public class MyConsumer implements Runnable {
 
        /*taking vector to use as buffer, 
         *it will keep numbers produced by Producer 
  *and work as synchronisation object
        */ 
        Vector<Integer> sharedQ;
 
 public MyConsumer(Vector<Integer> sharedQ) {
  this.sharedQ = sharedQ;
 }
 
 @Override
 public void run() {
  /*
   * loop will go on forever
   */
  while(true) {
      consumed();
     /*
      * making thread to sleep for random time after consuming  
      *so as to make output more readable and understandable
      *we can set any arbitrary sleeping time
      */
      try {
   Thread.sleep(((long)((Math.random())*20000)));
   
      } catch (InterruptedException e) {   
   e.printStackTrace();
      }
       }
 }
 /*
  * This method has the logic for consuming numbers 
         *and synchronization with producer
  */
 public void consumed() {
  // cheacking if buffer is empty-then consumer has to wait
   while(sharedQ.isEmpty()) {
    synchronized(sharedQ) {
     try {
      System.out.println(Thread.currentThread().getName()+" waiting...");
      sharedQ.wait();
     } catch (InterruptedException e) {
      
      e.printStackTrace();
     }
     
    }
   }
   //consuimng a number from the buffer
   synchronized(sharedQ) {
      System.out.println(Thread.currentThread().getName()+" consumed "+sharedQ.remove(0));
      //notifying other thread which are waiting on sharedQ
      sharedQ.notifyAll();
   }
  }
 
}

  Test class:

import java.util.Vector;

public class MyProducerConsumerTest { 
 
 public static void main(String args[]) {
  
        /*taking vector to use as buffer, 
         *it will keep numbers produced by Producer 
  *and work as synchronisation object
         */  
        Vector<Integer> sharedQ = new Vector<Integer>();
        // Size will store the maximum size of buffer
  final int SIZE = 5;
 //Making producer and consumer thread
 Thread producer = new Thread(new MyProducer(sharedQ,SIZE),"producer");
 Thread consumer = new Thread(new MyConsumer(sharedQ),"consumer");
  
 //starting producer/consumer threads
 producer.start();
 consumer.start();
 /*
  * this join is optional- 
  * after join this main thread will never finish as consumer/producer willl run forever
  * to see effect of join we need to make consumer/producer to run for some specific time
  */
  
 try {
  producer.join();
  consumer.join();
   
 } catch (InterruptedException e) {   
  e.printStackTrace();
 }
 /*
  * this will never get printed 
  * unless we remove join call made above or finish execution of producer/consumer threads
  */
 System.out.println("all done");
 }
}

We can make this code to work for multiple producer/consumer scenario just by changing test class and creating multiple threads for producer and consumer.

Modified Test class:

import java.util.Vector;

public class MyProducerConsumerTest { 
 
 public static void main(String args[]) {
  
        /*taking vector to use as buffer, 
         *it will keep numbers produced by Producer 
  *and work as synchronisation object
         */  
        Vector<Integer> sharedQ = new Vector<Integer>();
        // Size will store the maximum size of buffer
  final int SIZE = 5; 
 
     //Making producer and consumer thread
 Thread producer1 = new Thread(new MyProducer(sharedQ,SIZE),"producer1");
        Thread producer2 = new Thread(new MyProducer(sharedQ,SIZE),"producer2"); 
        Thread producer3 = new Thread(new MyProducer(sharedQ,SIZE),"producer3");
        Thread consumer1 = new Thread(new MyConsumer(sharedQ),"consumer1");
        Thread consumer2 = new Thread(new MyConsumer(sharedQ),"consumer2");
        Thread consumer3 = new Thread(new MyConsumer(sharedQ),"consumer3");
        Thread consumer4 = new Thread(new MyConsumer(sharedQ),"consumer4"); 
  
       //starting producer/consumer threads
 producer1.start();
        producer2.start();
        producer3.start(); 
        consumer1.start();
        consumer2.start();
        consumer3.start();
       consumer4.start(); 
        /*
  * this join is optional- 
  * after join this main thread will never finish as consumer/producer willl run forever
  * to see effect of join we need to make consumer/producer to run for some specific time
  */
  
 try {
  producer1.join();
                producer2.join();
               producer3.join(); 
                consumer1.join();
                consumer2.join();
                consumer3.join();
                consumer4.join(); 
        } catch (InterruptedException e) {   
  e.printStackTrace();
 }
 /*
  * this will never get printed 
  * unless we remove join call made above or finish execution of producer/consumer threads
  */
 System.out.println("all done");
 }
}

 

 

immutability in Java

An object is considered immutable if its state cannot change after it is constructed.

Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state.

Sections in this post: 

1. Strategy for defining immutable objects
2. Declaring class as final
3. Using factory methods and making constructor private
4. When mutable variables are present in class
5. Builder design pattern
6. Date Object in immutable class

Strategy for Defining Immutable Objects

The following rules define a simple strategy for creating immutable objects.

1. Don't provide "setter" methods — methods that modify fields or objects referred to by fields.
2. Make all fields final and private.
3. Set all instance data in the constructor.
4. Don't allow sub-classes to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods.
5. If the instance fields include references to mutable objects, don't allow those objects to be changed:
   • Don't provide methods that modify the mutable objects.
   • Clone mutable objects for which a reference to them is returned.
     
   • Clone mutable objects for which a reference to them is received.
     
   • Implement a deep clone if the default shallow clone is not correct for a properly behaved immutable object.

 Lets add all above rules and make something concrete class implementation.

By making class final:

This is the most simple way of making a class mutable.

public final class FinalPersonClass {       

      private final String name;
      private final int age;      

      public FinalPersonClass(final String name, final int age) { 

            super();
            this.name = name;
            this.age = age; 
      } 

      public int getAge() { 

            return age;
      } 

      public String getName() { 

            return name;
      }
} 

 Using Factory methods and making constructor private:

//No need to make class final here 
public class FinalPerson { 
          
     private final String name;
      private final int age;       

      private FinalPerson(final String name, final int age) { 

            super();
            this.name = name;
            this.age = age;
      } 

      public int getAge() { 

            return age;
      } 

      public String getName() { 

            return name; 
      } 

      public FinalPerson getFinalPerson(final String name, final int age) {
           return new FinalPerson(final String name, final int age);
     }
} 

Making a class immutable in Java, which includes mutable member variable.

When an immutable class is implemented, mutable objects passed to or returned from an immutable object must be properly cloned. Consider the following class declarations: a DiskDriveInfo class and a User class. The DiskDriveInfo is intended to be immutable. The User encapsulates which user has shared access to the disk drive. The User object with shared access is stored as part of the DiskDriveInfo object. In the following example, the designer of the class was careful to make the class final and all fields private, and to provide only getter methods. Is the DiskDriveInfo class immutable? If not, what needs to be done to make it so?

class User
{
  private String userName;
  private String userID;
  private int userNode;

  User(String name, int node)
  {
    userName = name;
    userNode = node;
  }
  public void setUserName(String name)
  {
    userName = name;
  }
  public void setUserID(String userid)
  {
    userID = userid;
  }
  public void setUserNode(int node)
  {
    userNode = node;
  }
  public String userName()
  {
    return userName;
  }
}

final class DiskDriveInfo
{
  private int driveSize;
  private String volumeLabel;
  private User driveShare;

  DiskDriveInfo(int size, String volLabel, User share)
  {
    driveSize = size;
    volumeLabel = volLabel;
    driveShare = share;
  }
  public int size()
  {
    return driveSize;
  }
  public String label()
  {
    return volumeLabel;
  }
  public User share()
  {
    return driveShare;
  }
}

The DiskDriveInfo class is not immutable. Objects of this class can be changed. Consider the following code that creates a DiskDriveInfo object and tests its immutability:

class Test
{
  private static final int sizeInMeg = 200;
  public static void main(String args[])
  {
    User share1 = new User("Duke", 10);                       //1
    DiskDriveInfo dd = new DiskDriveInfo(sizeInMeg, "myDrive",
                                         share1);             //2
    User share = dd.share();
    System.out.println("User with shared access is " +
                       share.userName());

    share1.setUserName("Fred");                               //3
    System.out.println("User with shared access is " +
                       share.userName());
  }
}

If we run the program we will get output like this:

Output

================================================================================

User with shared access is Duke
User with shared access is Fred

What went wrong? This code creates a User object, share1, at //1, with the user name Duke. A supposedly immutable DiskDriveInfo object is created at //2 and is passed a reference to the User object. The DiskDriveInfo object is queried, and the shared owner, Duke, is printed. The User object, share1, changes its name to Fred at //3. When the DiskDriveInfo object is queried again for the user name, it discovers that the name changed from Duke to Fred.
The problem is that the DiskDriveInfo constructor receives a reference to the User object and does not make a copy, or clone, of this object. Therefore, the DiskDriveInfo constructor receives a copy of the reference to the User object. Now the DiskDriveInfo object's driveShare field and the local variable, share1, in main of class Test, reference the same object. Therefore, any changes made through either reference affect the same object. Figure shows the object layout after the code at //1 is executed.

 
After the code at //2 is executed, the object layout looks as shown in Figure


Notice that because the reference to the User object is not cloned, both the share1 and driveShare references share the same User object. After the code at //3 is executed, the object layout as shown in Figure.



To correct this problem, the DiskDriveInfo class must clone any mutable object to which it receives a reference. It then has a reference to its own copy of the object that cannot be changed by other code.
The modified DiskDriveInfo class that supports cloning looks like this:

final class DiskDriveInfo
{
  //As before...
  DiskDriveInfo(int size, String volLabel, User share)
  {
    driveSize = size;
    volumeLabel = volLabel;
    driveShare = (User)share.clone();
  }
  public User share()
  {
    return (User)driveShare.clone();
  }
}

 Because you are cloning the User object, its definition must change as well.

class User implements Cloneable
{
  //As before...
  public Object clone()
  {
    try {
      return super.clone();
    }
    catch (CloneNotSupportedException e) {
      //This should not happen, since this class is Cloneable.
      throw new InternalError();
    }
  }
}

 With these changes to the User object, running the previous test code produces the correct output:

Output

================================================================================

User with shared access is Duke
User with shared access is Fred

Because the User object is cloned on the constructor call, the code that subsequently changes the User object at //1 has no effect on the DiskDriveInfo object. The implementation of the immutable DiskDriveInfo class is now correct. The object layout looks as shown in Figure

Achieving Immutability with Builder Design Pattern:

In most of the classes in our real applications there are many fields. Also, most of these fields are not mandatory for object creation. For example, a user in a real application will have a username, password, firstname, lastname, creationDate, emailAddress, etc., but for user creation here, only a username and password are required. 

The Builder Pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.
The builder design pattern provides a way for you to build complex immutable objects. The process is:

1. The client calls a constructor (or static factory) with all the required parameters and gets a builder object.
2. The client calls setter like methods to set each optional parameter of interest.
3. Finally the client calls the build method to generate the object which is immutable.

import java.math.BigDecimal;

/**
* Immutable, hence thread safe CashBalance objec
*/

public final class CashBalance {
  
 private BigDecimal initialBalance, totCredits, totDebits;
  
  //construct
  public CashBalance(CashBalanceBuilder builder) {
  this.initialBalance = builder.initialBalance;
  this.totCredits = builder.totCredits;
  this.totDebits = builder.totDebits;
 }
    
 public static class CashBalanceBuilder {
   
  //has same fields as the object it is going to build
   protected BigDecimal initialBalance, totCredits, totDebits;
  //define the setters that return itself
   CashBalanceBuilder setInitialBalance(BigDecimal initialBalance) {
   this.initialBalance = initialBalance;
   return this;
  }
   CashBalanceBuilder setTotCredits(BigDecimal totCredits) {
    this.totCredits = totCredits;
   return this;
  }
  CashBalanceBuilder setTotDebits(BigDecimal totDebits) {
   this.totDebits = totDebits;
   return this;
  }
 }
  
 //only getter methods and no setter methods as it is an immutable object
}

The client code will look like this :

public static void main(String[] args) {
   CashBalance.CashBalanceBuilder builder = 
           new CashBalance.CashBalanceBuilder(
                    .setInitialBalance(BigDecimal.valueOf(250.00))
                    .setTotCredits(BigDecimal.valueOf(250.00))
                    .setTotDebits(BigDecimal.valueOf(250.00));
                    CashBalance bal = new CashBalance(builder);
}

How to use Date object in immutable class

This is a commonly asked scenario in interviews while discussing about immutable classes.
Some time you may need to write immutable class which includes mutable classes like java.util.Date, despite storing Date into final field it can be modified internally, if internal date is returned to the client. In order to preserve immutability in such cases, its advised to return copy of original object.

Consider the below code:

public final class ImmutableReminder{

    private final Date remindingDate;
  

    public ImmutableReminder (Date remindingDate)
    {
        if(remindingDate.getTime() < System.currentTimeMillis()){

            throw new IllegalArgumentException("Can not
                   set reminder” + “ for past time: " + remindingDate);
         }
         // creating new object of Date first
this.remindingDate = new Date(remindingDate.getTime());
    }

    public Date getRemindingDate() {
      //returning clone of the date object 
     return (Date) remindingDate.clone();
    }
} 

serialVersionUID

When you serialize an object using Serialization mechanism (by implementing Serializable interface), there is a possibility that you may face versioning issues and because of these versioning issues, you will not be able to deserialize the object.

Sections in this post: 

1. Problem to face
2. Root of the problem
3. Solution
4. What is serialVersionUID
5. Example
6. When to update serialVersionUID
1. Compatible changes
2. Incompatible changes

Problem scenario....

lets say you created a class, instantiated it, and wrote it out to an object stream. That flattened object sits in the file system for some time. Meanwhile, you update the class file, perhaps adding a new field. Now try to read the flattened object. An exception "java.io.InvalidClassException" will be thrown.

 Root of the problem

lets first see what is actually causing this problem? Why should any change in a serialized class throw "InvalidClassException". During object serialization, the default Java serialization mechanism writes the metadata about the object, which includes the class name, field names and types, and superclass. All this information is stored as part of the serialized object.
When you deserialize the object, this information is read to reconstitute the object. But to perform the deserialization, the object needs to be identified first and this will be done by serialVersionUID. So everytime an object is serialized the java serialization mechanism automatically computes a hash value using ObjectStreamClass’s computeSerialVersionUID() method by passing the class name, sorted member names, modifiers, and interfaces to the secure hash algorithm (SHA), which returns a hash value, the serialVersionUID.

Now when the serilaized object is retrieved, the JVM first evaluates the serialVersionUID of the serialized class and compares the serialVersionUID value with the one of the object. If the sserialVersionUID values match then the object is said to be compatible with the class and hence it is de-serialized. If not InvalidClassException exception is thrown.

 And the solution is...

The solution is very simple. Instead of relying on the JVM to generate the serialVersionUID, you explicitly mention (generate) the serialVersionUID in your class. The syntax is:

 private final static long serialVersionUID = <integer value> 

What is serialVersionUID? 

Its a static, private variable in the class. Once you define the serialVersionUID in your class explicitly, you don't need to update it until and unless you make the incompatible changes.
 
Example:

Consider the same example taken from serialization post to explain the issue and importance of maintaining serialVersionUID.

 

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Calendar;
import java.util.Date;

public class MyDateObject implements Serializable{
   
    //first time we keep serial VersionUID as 1L
    private static final long serialVersionUID = 1L;
    private Date date;

    public MyDateObject() {
        //date= Calendar.getInstance().getTime();
         calculateCurrentTime();
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date=date;
     } 
    
    private void calculateCurrentTime(){
        date = Calendar.getInstance().getTime();
    }
    
    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
    }

    private void readObject(ObjectInputStream in) 
        throws IOException, ClassNotFoundException{

        // our "pseudo-constructor"
        in.defaultReadObject();
        // now perfrom same operation you need to do in constructor
        calculateCurrentTime();
    }
}

 Class to serialize MayDate object :

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;

//Class to persist the time in a flat file time.ser
public class WriteSerialClass {

  public static void main(String [] args) {
      String filename = "c://time.txt";

      if(args.length > 0){
          filename = args[0];
      }
       
      MyDateObject time = new MyDateObject();
      FileOutputStream fos = null;
      ObjectOutputStream out = null;

      try{
          fos = new FileOutputStream(filename);
          out = new ObjectOutputStream(fos);
          out.writeObject(time);
          out.close();
      }catch(IOException ex){
          ex.printStackTrace();
      }
   }
} 

Class to De-serialize MydateObject:

import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.util.Calendar;

public class ReadSerialClass   {

     public static void main(String [] args) {
            String filename = "c://time.txt";

            if(args.length > 0){
                filename = args[0];
            }
            
            MyDateObject time = null;
            FileInputStream fis = null;
            ObjectInputStream in = null;

            try{
                fis = new FileInputStream(filename);
                in = new ObjectInputStream(fis);
                time = (MyDateObject)in.readObject();
                in.close();
            }catch(IOException ex){
                ex.printStackTrace();
            }catch(ClassNotFoundException cnfe){
                cnfe.printStackTrace();
            }

            // print out restored time
            System.out.println("Restored time: " + time.getDate());

            // print out the current time
            System.out.println("Current time: " 
                + Calendar.getInstance().getTime());

         }
     } 

Output:

=======================================================

Restored time: Wed May 28 18:11:41 IST 2014
Current time: Wed May 28 18:11:42 IST 2014 

 

 Now run the following program again by changing serialVersionUID value in myDateObject class:

 

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Calendar;
import java.util.Date;

public class MyDateObject implements Serializable{
   
   //Now we change serial VersionUID as 2L
    private static final long serialVersionUID = 2L;
    private Date date;

    public MyDateObject() {
        //date= Calendar.getInstance().getTime();
         calculateCurrentTime();
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date=date;
     } 
    
    private void calculateCurrentTime(){
        date = Calendar.getInstance().getTime();
    }
    
    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
    }

    private void readObject(ObjectInputStream in) 
        throws IOException, ClassNotFoundException{

        // our "pseudo-constructor"
        in.defaultReadObject();
        // now perfrom same operation you need to do in constructor
        calculateCurrentTime();
    }
}

Output:

=========================================================

java.io.InvalidClassException: com.MyDateObject; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2
    at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
    at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
    at java.io.ObjectInputStream.readClassDesc(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readObject(Unknown Source) 

 The reason of the above error is the version change and exactly this is the reason for maintaining the version.
By maintaining version we keep the serialization/de-serialiation consistent

When to update serialVersionUID?

Adding serialVersinUID manually to the class does not mean that it should never be updated and never need not be updated. There is no need to update the serialVersionUID if the change in the class is compatible but it should be updated if the change is incompatible

Some of compatible changes are:

• Adding field.
• Adding classes.
• Removing classes.
• Adding writeObject/readObject methods.
• Removing writeObject/readObject methods.
• Adding java.io.Serializable.
• Changing the access to a field.
• Changing a field from static to nonstatic or transient to nontransient.

  Some of the Incompatible changes  are:

• Deleting fields.
• Moving classes up or down the hierarchy.
• Changing a nonstatic field to static or a nontransient field to transient.
• Changing the declared type of a primitive field.
• Changing the writeObject or readObject method.
• Changing a class from Serializable to Externalizable or visa-versa.
• Removing either Serializable or Externalizable. 
• Adding the writeReplace or readResolve method. 

Serialization in Java

Serialization is the process of converting an object's state (including its references) to a sequence of bytes, as well as the process of rebuilding those bytes into a live object at some future time.

Sections in this post: 

1. Some uses of serailization
2. Serializable Interface
3. Serialization steps
4. readObject and writeObjectMethods
5. FAQ

Serialization is used when you want to persist the object. It is also used by RMI to pass objects between JVMs, either as arguments in a method invocation from a client to a server or as return values from a method invocation. In general, serialization is used when we want the object to exist beyond the lifetime of the JVM. 

Here are some uses of serialization

• To persist data for future use.
• To send data to a remote computer using such client/server Java technologies as RMI or socket programming.
• To "flatten" an object into array of bytes in memory.
• To exchange data between applets and servlets.
• To store user session in Web applications.
• To activate/passivate enterprise java beans.
• To send objects between the servers in a cluster. 

Java provides Serialization API, a standard mechanism to handle object serialization. To persist an object in java, we need to follow following steps.

1.  the first step is to flatten the object. For that the respective class should implement "java.io.Serializable" interface. We don't need to implement any methods as this interface do not have any methods. This is a marker interface/tag interface. Marking a class as Serializable indicates the underlying API that this object can be flattened. 

import java.io.Serializable;
import java.util.Calendar;
import java.util.Date;

public class MyDateObject implements Serializable{

    private static final long serialVersionUID = -5315058568373987829L;
    private Date date;

    public MyDateObject() {
        date= Calendar.getInstance().getTime();
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date=date;
     }
}

     2.  Next step is to actually persist the object. To persist an object we need to use node stream to write to file systems or transfer a flattened object across a network. We can use java.io.ObjectOutputStream class for this. So to write an object you use "writeObject(<<instance>>)" method of "java.io.ObjectOutputStream" class and to read an object you use "readObject()" method of "java.io.ObjectOutputStream" class.

Note:  "readObject()" can read only serialized object, that means if the class does not implement "java.io.Serializable" interface, "readObject()" cannot read that object.

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;


//Class to persist the time in a flat file time.txt
public class WriteSerializeClass {

  public static void main(String [] args) {
       String filename = "c://time.txt";
       if(args.length > 0){
          filename = args[0];
       }       

      MyDateObject time = new MyDateObject();
      FileOutputStream fos = null;
      ObjectOutputStream out = null;

      try{

          fos = new FileOutputStream(filename);
          out = new ObjectOutputStream(fos);
          out.writeObject(time);
          out.close();
      }catch(IOException ex){
          ex.printStackTrace();
      }
   }
}

    

import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.util.Calendar;
//Class to read the time from a flat file time.txt
public class ReadSerializeClass   {

  public static void main(String [] args) {
         String filename = "c://time.txt";

         if(args.length > 0){
             filename = args[0];
         }
   
         MyDateObject time = null;
         FileInputStream fis = null;
         ObjectInputStream in = null;

         try{
             fis = new FileInputStream(filename);
             in = new ObjectInputStream(fis);
             time = (MyDateObject)in.readObject();
             in.close();
         }catch(IOException ex){
             ex.printStackTrace();
         }catch(ClassNotFoundException cnfe){
             cnfe.printStackTrace();
         }

         // print out restored time
         System.out.println("Restored time: " + time.getDate());

         // print out the current time
         System.out.println("Current time: " 
                      + Calendar.getInstance().getTime());
      }
  }

readObject and writeObject methods:

 To enhance the normal process of serialization/de-serialization provide two methods inside your serializable class. Those methods are:

1. private void writeObject(ObjectOutputStream out) throws IOException;
2. private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException; 

   Let's look at one example

Without readObjet()/writeObject()

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Calendar;
import java.util.Date;

public class MyDateObject implements Serializable{
    
 
    private static final long serialVersionUID = -5315058568373987829L;
    private Date date;

    public MyDateObject() {
        //date= Calendar.getInstance().getTime();
        calculateCurrentTime();
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
     this.date=date;
     } 
    
    private void calculateCurrentTime(){
        date = Calendar.getInstance().getTime();
    }
 }

Output:
=================================================================

 Restored time: Wed May 28 15:54:31 IST 2014
Current time: Wed May 28 15:54:34 IST 2014

Now we will add the two methods:  readObjet()/writeObject()

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Calendar;
import java.util.Date;

public class MyDateObject implements Serializable{    
 
   private static final long serialVersionUID = -5315058568373987829L;
   private Date date;

    public MyDateObject() {
        //date= Calendar.getInstance().getTime();
        calculateCurrentTime();
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date=date;
     } 
    
    private void calculateCurrentTime(){
        date = Calendar.getInstance().getTime();
    }    //Adding writObject()
    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
    }      //Adding readObject()
    private void readObject(ObjectInputStream in) 
                         throws IOException, ClassNotFoundException{

         in.defaultReadObject();
        // now perfrom same operation you need to do in constructor
        calculateCurrentTime();
    }
}

Output:

=========================================================================

Restored time: Wed May 28 16:08:26 IST 2014
Current time: Wed May 28 16:08:26 IST 2014

 So by overriding these two methods, we can easily get desired serialization/de-serialization behavior.

Note:  serialization does not care about access modifiers. It serializes all private, public and protected fields.

Again there is one more way to serialize the object - create your own protocol with the Externalizable interface. Instead of implementing the Serializable interface, you can implement Externalizable, which contains two methods:

1. public void writeExternal(ObjectOutput out) throws IOException; 
2. public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException;

The Externalization is discussed as separate post. Check it out here .

Some FAQ:

1. why readObject And writeObject declared as private?

     Ans:  We don't want these methods to be overridden by subclasses. Instead, each class can have its own writeObject method, and the serialization engine will call all of them one after the other. This is only possible with private methods (these are not overridden). (The same is valid for readObject.)
That's why  both methods are declared private . The trick here is that the virtual machine will automatically check to see if either method is declared during the corresponding method call. The virtual machine can call private methods of your class whenever it wants but no other objects can. Thus, the integrity of the class is maintained and the serialization protocol can continue to work as normal. 

 2. How stop from serailizing one of the sub class of a serializable class?

Ans:To stop the automatic serialization, we can once again override the readObject/writeObject  methods to just throw the NotSerializableException in our class.

private void writeObject(ObjectOutputStream out) throws IOException{

    throw new NotSerializableException("Dont Serialize");
}

private void readObject(ObjectInputStream in) throws IOException{

    throw new NotSerializableException("Dont Serialize");
}