Transient variables cannot be serialized. The fields marked transient in a serializable object will not be transmitted in the byte stream. An example would be a file handle, a database connection, a system thread etc. Such objects are only meaningful locally. So they should be marked as transient in a serializable class.
Serialization can adversely affect performance since it:
- Depends on reflection.
- Has an incredibly verbose data format.
- Is very easy to send surplus data.
When to use serialization?
Do not use serialization if you do not have to. A common use of serialization is to use it to send an object over the network or if the state of an object needs to be persisted to a flat file or a database. (Refer Q57 on Enterprise section). Deep cloning or copy can be achieved through serialization. This may be fast to code but will have performance implications
To serialize the above “Car” object to a file (sample for illustration purpose only, should use try {} catch {} block):
Car car = new Car(); // The “Car” class implements a java.io.Serializable interface FileOutputStream fos = new FileOutputStream(filename); ObjectOutputStream out = new ObjectOutputStream(fos); out.writeObject(car); // serialization mechanism happens here
out.close();
The objects stored in an HTTP session should be serializable to support in-memory replication of sessions to achieve scalability. Objects are passed in RMI (Remote Method Invocation) across network using serialization.
What is Java Serial Version ID?
Say you create a “Car” class, instantiate it, and write it out to an object stream. The flattened car object sits in the file system for some time. Meanwhile, if the “Car” class is modified by adding a new field. Later on, when you try to read (i.e. deserialize) the flattened “Car” object, you get the java.io.InvalidClassException – because all serializable classes are automatically given a unique identifier. This exception is thrown when the identifier of the class is not equal to the identifier of the flattened object. If you really think about it, the exception is thrown because of the addition of the new field. You can avoid this exception being thrown by controlling the versioning yourself by declaring an explicit serialVersionUID. There is also a small performance benefit in explicitly declaring your serialVersionUID (because does not have to be calculated). So, it is best practice to add your own serialVersionUID to your Serializable classes as soon as you create them as shown below:
public class Car {
static final long serialVersionUID = 1L; //assign a long value
}
Note: Alternatively you can use the serialver tool comes with Sun’s JDK. This tool takes a full class name on the command line and returns the serialVersionUID for that compiled class. For example: static final long serialVersionUID = 10275439472837494L; //generated by serialver tool.
No comments:
Post a Comment