The difference between serializable and externalizable is the popular java interview question which we have touched on in my earlier post on Serialization: Top 10 java serialization interview questions. knowing differences between externalizable and serializable is not just important from the interview point of view but also getting control of the serialization process and optimizing the performance of serialization. both serializable and externalizable are used to serialize or persist java objects but the way they do is a little different.
In the case of Serializable Java Virtual machine has full control for serializing objects while in the case of Externalizable, the application gets control for persisting objects.
In the case of Serializable Java Virtual machine has full control for serializing objects while in the case of Externalizable, the application gets control for persisting objects.
Both writeExternal() and readExternal() method provides complete control on the format and content of the Serialization process to the application which can be leveraged to increase the performance and speed of the serialization process.
And, If you are a beginner then I also recommend you to join these free Java Programming courses to learn Java in a better and more structured way. These are the best and up-to-date free courses to learn Java online.
Serialization and Externalization in Java
here are some more differences between Serializable and Externalizable interfaces in Java:
1. In the case of Serializable, the default serialization process is used. while in the case of Externalizable custom Serialization process is used which is implemented by the application.
2. JVM gives call back to readExternel() and writeExternal() of java.io.Externalizalbe interface for restoring and writing objects into persistence.
3. Externalizable interface provides complete control of serialization process to application.
4. readExternal() and writeExternal() supersede any specific implementation of writeObject and readObject methods.
Though Externalizable provides complete control, it also presents challenges to serialize super type state and take care of default values in case of transient variable and static variables in Java. If used correctly Externalizable interface can improve the performance of the serialization process.
That’s all on the difference between Externalizable and Serializable interface in Java. This is always asked when Java interviews take turns towards Serialization after Multithreading questions and Collections Interview questions.
The only problem with Serialization is that not many programmers use it and that’s why it looks little difficult otherwise once you are familiar with Serialization process and rules of Serialization, interview questions can be more easily handled.
Some Interview Questions post:
Thanks for reading this article so far. Let me know if this question was asked to you on any Java interview? Also what is your favorite Java question related to Serialization?
8 comments :
an important difference is that Serializable will call all of the superclasses, and Externalizable will not.
Hi Javin gr8 article ....few things that I want to add..
By implementating java.io.Serializable, you get "automatic" serialization capability for objects of your class. No need to implement any other logic, it'll just work. The Java runtime will use reflection to figure out how to marshal and unmarshal your objects.
In earlier version of Java, reflection was very slow, and so serializaing large object graphs (e.g. in client-server RMI applications) was a bit of a performance problem. To handle this situation, the java.io.Externalizable interface was provided, which is like java.io.Serializable but with custom-written mechanisms to perform the marshalling and unmarshalling functions (you need to implement readExternal and writeExternal methods on your class). This gives you the means to get around the reflection performance bottleneck.
In recent versions of Java (1.3 onwards, certainly) the performance of reflection is vastly better than it used to be, and so this is much less of a problem. I suspect you'd be hard-pressed to get a meaningful benefit from Externalizable with a modern JVM.
Also, the built-in Java serialization mechanism isn't the only one, you can get third-party replacements, such as JBoss Serialization, which is considerably quicker, and is a drop-in replacement for the default.
A big downside of Externalizable is that you have to maintain this logic yourself - if you add, remove or change a field in your class, you have to change your writeExternal/readExternal methods to account for it.
In summary, Externalizable is a relic of the Java 1.1 days. There's really no need for it any more
@SARAL SAXENA
Did you copy-paste your comments from following ?? LOL !!!
http://stackoverflow.com/questions/817853/what-is-the-difference-between-serializable-and-externalizable-in-java
Tip: ValjoGen can generate java value objects for you that implement Externalizable (and much more) for you so you do not have to write the code manually. ValjoGen is free open source at the website is at http://valjogen.41concepts.com.
Thanks @Unknown, this looks like a good utility which will minimize mistakes Java developers make while using Externalizable interface.
Some few points that I came across:
Serialization is a recursive algorithm. What I mean to say here is, apart from the fields that are required, starting from a single object, until all the objects that can be reached from that object by following instance variables, are also serialized. This includes the super class of the object until it reaches the "Object" class and the same way the super class of the instance variables until it reaches the "Object" class of those variables. Basically all the objects that it can read. This leads to lot of overheads.
Both serializing and deserializing require the serialization mechanism to discover information about the instance it is serializing. Using the default serialization mechanism, will use reflection to discover all the field values. Also the information about class description is added to the stream which includes the descption of all the serializable superclasses, the description of the class and the instance data associated with the specific instance of the class. Lots of data and metadata and again performance issue.
You know that serialization needs serialVersionUID, a unique Id to identify the information persisted. If you dont explicitly set a serialiVersionUID, serialization will compute the serialiVersionUID by going through all the fields and methods. So based on the size of the class, again serialization mechanism takes respective amount of time to calculate the value. A third performance issue.
Externalizable interface is not a marker interface and it provides two methods - writeExternal and readExternal.
Externalization efficiency comes at a price. The default serialization mechanism adapts to application changes due to the fact that metadata is automatically extracted from the class definitions (observe the format above and you will see that when the object is serialized by implementing Serializable interface, the class metadata(definitions) are written to the persistent store while when you serialize by implementing Externalizable interface, the class metadata is not written to the persistent store). Externalization on the other hand isn't very flexible and requires you to rewrite your marshalling and demarshalling code whenever you change your class definitions.
As you know a default public no-arg constructor will be called when serializing the objects that implements Externalizable interface. Hence, Externalizable interface can't be implemented by Inner Classes in Java as all the constructors of an inner class in Java will always accept the instance of the enclosing class as a prepended parameter and therefore you can't have a no-arg constructor for an inner class. Inner classes can achieve object serialization by only implementing Serializable interface.
If you are subclassing your externalizable class, you have to invoke your superclass’s implementation. So this causes overhead while you subclass your externalizable class. Observe the examples above where the superclass writeExternal method is explicitly called in the subclass writeExternal method.
Methods in externalizable interface are public. So any malicious program can invoke which results into loosing the prior serialized state.
Nice info Rajat!
But using readObject & writeObject method, we can customize the read & write of operation provided by the serializable interface. I really want to know why do we have the externalizable interface when there is readObject & writeObject method exist to override serialization logic.
Post a Comment