I understood from this posting that Serializable is incredibly easy to implement, and resilient to change (in most cases all you have to do is update the serialversionUID). If we want to control of read and write process we can implement Externalizable.
If all we want is the control of read and write process, we can override the below methods for serialization right? why do we need to introduce the new interface Externalizable?
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
private void readObjectNoData()
throws ObjectStreamException;
Externalization provides implementation logic control to the application by overriding readExternal and writeExternal methods. In serializable interface uses reflection which causes relatively slow performance. Externalizable gives full control over the implementation approach.
Serializable interface passes the responsibility of serialization to JVM and the programmer has no control over serialization, and it is a default algorithm. The externalizable interface provides all serialization responsibilities to a programmer and hence JVM has no control over serialization.
Serialization is a mechanism of converting the state of an object into a byte stream. Deserialization is the reverse process where the byte stream is used to recreate the actual Java object in memory. This mechanism is used to persist the object.
Serializable is a marker interface i.e. does not contain any method. Externalizable interface contains two methods writeExternal() and readExternal() which implementing classes MUST override. Serializable interface pass the responsibility of serialization to JVM and it's default algorithm.
You ask:
why do we need to introduce the new interface
Externalizable
?
The best rationale I've been able to find (in Oracle documentation) is in the WebLogic JMS Best Practice document (original link):
"The CPU cost of serializing Java objects can be significant. This expense, in turn, affects JMS Object messages. You can offset this cost, to some extent, by having application objects implement java.io.Externalizable, but there still will be significant overhead in marshalling the class descriptor. To avoid the cost of having to write the class descriptors of additional objects embedded in an Object message, have these objects implement Externalizable, and call readExternal and writeExternal on them directly. For example, call obj.writeExternal(stream) rather than stream.writeObject(obj). Using Bytes and Stream messages is generally a preferred practice."
In short, you can get better performance using Externalizable
, at least in some situations.
And "the difference" is that if you use Serializable
the work of serialization is typically done for you, but with Externalizable
you need to code it yourself.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With