Background:
There has been good amount of documentation already about serialization concept and how Java achieves it but generally such documentation talks only about a subset of what serialization offers us. This set of two articles aims at making the concept clear in the first part. And then in the second part, we will talk about lesser known and more complex facts about serialization.
Serialization concept:
It is an obvious fact that Java allows us (programmers) to create objects and store them in memory for re-use. However the life of any object in Java is at max limited till the time the actual JVM is alive. Once the JVM shuts down, however nice and useful our object is, next time we can't use it as it is.
So what should we do if we want to keep our object alive even after JVM shuts down and we want to use it the next time JVM comes up ? Is there a way we can use the same nice object in some different JVM altogether?
Well to answer these question,serialization comes to our rescue.
Time for definition:
Serialization is a process by which we can persist an object (as it stands in JVM or object state to be more technical) as sequence of bytes (may be in a file or in db or some othere storage) and then bring back the object in JVM (same or different) so that it can be reused whenever required.
It is obvious from the definition that we can flatten an object and store it for later use now in next section we will see how Java does it.
How java does it:
There are 3 ways in which we can persist any object. We will start with the most basic method and then work our way to the more complex ways to implement serialization. Before we start with the first way, we will talk about which object we can serialize and which ones we can't or shouldn't.
#1. An object can be serialized as long as it implements "Serializable" interface.
This is the first and most important rule we should remember about serialization. Serializable interface is a 'Marker' interface meaning it doesn't have any methods defined on it. It is just to tag a particular object to let JVM know that it can be serialized.
Now what happens when an object implements serializable interface but it has another object as an instance variable and that object to our misery doesn't implement the interface. Can we still serialize our object ?
Think about it, if we want to store the object and be able to reuse it later, we should be storing the entire object otherwise if we just store partial state of the object, that can lead to pretty frustating and potentially disastrous scenarios. So next rule (or ammendment to the first rule) is
#2. In order to serialize an object, all the referred objects within the object to be serialized MUST implement the "Serializable" interface.
Now think about another important fact, if java creators wanted serialization to be available for all objects across the board, they would have made the "Object" class imlpement the "Serializable" interface. But it isn't so. What might be the reason?
It is easy. There are objects, we don't want anybody to be able to serialize e.g. live 'Connection' object; imagine somebody serialize the active db connection and then wanting to use it later. It doesn't make any sense. So it is important to remember that not all objects are to be serialized.
One more thing before we dive into the different serialization mechanisms. Imagine we have a "BlogPost" object which has a member variable as "noOfViews". Now this variable represents the number of times the post is viewed. This variable is updated asynchronously by different threads at the same time. Now it doesn't make any sense to store the value of this variable when we serialize the BlogPost object. (This may not be the best example around but you should get the general idea) So what to do in such scenarios ?
Easy, java is always two steps ahead of us so it has a provision for this. Just mark the variable as "transient" and java's serialization mechanism will ignore the variable while storing the object. Easy... isn't it ?
#3 Mark the variables 'transient' if we don't want the values of these variables to be persisted while serializing.
Now we can talk about the first and default serialization mechanism
Default serialization mechanism:
If our object implements the above mentioned 'Serializable' interface, we are done :) java itself takes care of all the other things for us while serializing the object. Following example will explain how this works
Now we will see how it can be serialized
We can stop here for now. In the next part we will talk about the other two ways of serializing an object.
See you then.. :) Have a nice time learning Serialization.
There has been good amount of documentation already about serialization concept and how Java achieves it but generally such documentation talks only about a subset of what serialization offers us. This set of two articles aims at making the concept clear in the first part. And then in the second part, we will talk about lesser known and more complex facts about serialization.
Serialization concept:
It is an obvious fact that Java allows us (programmers) to create objects and store them in memory for re-use. However the life of any object in Java is at max limited till the time the actual JVM is alive. Once the JVM shuts down, however nice and useful our object is, next time we can't use it as it is.
So what should we do if we want to keep our object alive even after JVM shuts down and we want to use it the next time JVM comes up ? Is there a way we can use the same nice object in some different JVM altogether?
Well to answer these question,serialization comes to our rescue.
Time for definition:
Serialization is a process by which we can persist an object (as it stands in JVM or object state to be more technical) as sequence of bytes (may be in a file or in db or some othere storage) and then bring back the object in JVM (same or different) so that it can be reused whenever required.
It is obvious from the definition that we can flatten an object and store it for later use now in next section we will see how Java does it.
How java does it:
There are 3 ways in which we can persist any object. We will start with the most basic method and then work our way to the more complex ways to implement serialization. Before we start with the first way, we will talk about which object we can serialize and which ones we can't or shouldn't.
#1. An object can be serialized as long as it implements "Serializable" interface.
This is the first and most important rule we should remember about serialization. Serializable interface is a 'Marker' interface meaning it doesn't have any methods defined on it. It is just to tag a particular object to let JVM know that it can be serialized.
Now what happens when an object implements serializable interface but it has another object as an instance variable and that object to our misery doesn't implement the interface. Can we still serialize our object ?
Think about it, if we want to store the object and be able to reuse it later, we should be storing the entire object otherwise if we just store partial state of the object, that can lead to pretty frustating and potentially disastrous scenarios. So next rule (or ammendment to the first rule) is
#2. In order to serialize an object, all the referred objects within the object to be serialized MUST implement the "Serializable" interface.
Now think about another important fact, if java creators wanted serialization to be available for all objects across the board, they would have made the "Object" class imlpement the "Serializable" interface. But it isn't so. What might be the reason?
It is easy. There are objects, we don't want anybody to be able to serialize e.g. live 'Connection' object; imagine somebody serialize the active db connection and then wanting to use it later. It doesn't make any sense. So it is important to remember that not all objects are to be serialized.
One more thing before we dive into the different serialization mechanisms. Imagine we have a "BlogPost" object which has a member variable as "noOfViews". Now this variable represents the number of times the post is viewed. This variable is updated asynchronously by different threads at the same time. Now it doesn't make any sense to store the value of this variable when we serialize the BlogPost object. (This may not be the best example around but you should get the general idea) So what to do in such scenarios ?
Easy, java is always two steps ahead of us so it has a provision for this. Just mark the variable as "transient" and java's serialization mechanism will ignore the variable while storing the object. Easy... isn't it ?
#3 Mark the variables 'transient' if we don't want the values of these variables to be persisted while serializing.
Now we can talk about the first and default serialization mechanism
Default serialization mechanism:
If our object implements the above mentioned 'Serializable' interface, we are done :) java itself takes care of all the other things for us while serializing the object. Following example will explain how this works
public class Employee implements Serializable
{
private String name;
private int age;
//Getters and setters for the fields
}
Now we will see how it can be serialized
Employee employee = new Employee();FileOutputStream f= null;
ObjectOutputStream outStream = null;
try
{
f = new FileOutputStream(filename);outStream = new ObjectOutputStream(f);outStream.writeObject(employee);outStream.close();
}
catch(IOException ex)
{
ex.printStackTrace();
}
We can stop here for now. In the next part we will talk about the other two ways of serializing an object.
See you then.. :) Have a nice time learning Serialization.
