Java Serialization: Persist Your Objects, Page 2
Understanding Transient Keyword
The transient modifier is very handy in cases where you need to avoid serializing certain information from the object's state. Transient modifiers could be threads, database connections, sockets, I/O streams, etc. There is no point in serializing these objects, as their states could be indeterminable when they are recreated. It is also possible that the source for a database connection no longer exists.
Though using transient keywords effectively looks tough, it's fairly simple. You just need to associate the attribute with a transient keyword and the serialization API takes care of the rest. All attributes that are associated with the transient keyword will not be serialized when object serialization takes place.
Object Serializing with Your Own Protocol
Most Java applications are well served by their default serialization protocol, but developers still have a choice to customize the serialization protocol with their own. Java supports this is by implementing the Externalizable interface, which has two methods with the following signatures.
public void writeExternal(ObjectOutput) throws IOException public void readExternal(ObjectInput) throws IOException, ClassNotFoundException
Here, you can adjust the implementation for serializing and de-serializing to meet your requirements. You could serialize the object and have other primitive data types with it as well. The de-serialization process is just the reverse of the serialization process. The most important aspect here is that the de-serialization implementation can be proprietary, which can be useful in addressing security concerns. You can ensure that the de-serialized object you have created is not tampered with by using hash codes, which you can maintain in a proprietary placeholder.
You can also serialize states of previously ignored objects, such as database connections, provided you are certain that the connection is available with the right set of parameters required to serialize the object. I do not advise this approach.
Here are a couple of other serialization advisories:
- During de-serialization, it is never a good idea to create an instance of the object with values for its attributes. You need to always use the default constructor, which has no arguments. You can fill up values for all the object's attributes later when it is created.
- Serialization has its own file I/O impact on application performance. Analyzing the procedure carefully reveals that the standard file I/O operations are performed during serialization and de-serialization, with the complications of file I/O hidden from the developer. Of course, if you used the Externalizable interface, this complication is still present.
In some cases, you should not allow the objects you expose to be serialized. This is easy to do as well. Just overwrite the methods for the Externalizable interface and provide no implementation to the
readExternal(...) methods. This will ensure that no one can serialize the object.
The requirement for avoiding serialization could be as simple as supporting the Singleton pattern or preventing confidential information from circulating as files. The objects that you expose could be used by others in their runtimes, but they could not use the data available in other applications that breach contract/security.
Not a New Technology
Serialization is not a new technology that developers will have to learn from scratch. It is an idea/concept that all you are exposed to in most of your applications when you use the I/O package. This is just an advanced form of that concept with most of the little hurdles of file I/O hidden. The most important takeaway here is that serialization can be customized to the algorithms that you need; thereby increasing the security of the serialized data.
For Further Reading
About the AuthorSridhar M S is a Java developer from Bangalore, India. He holds a master's degree in Computer Science.