I'm Singaram Subramanian, and I work with CSC India as a Software Developer. My blog is an attempt to share my learnings with all (mainly, for those who desperately mine google finding ways to solve problems, fix issues, learn about a Java/Open source software, or deciding on tough choices etc. during software development as I do). Singaram is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Marshalling / Unmarshalling Java Objects: Serialization vs Externalization

02.01.2012
| 14045 views |
  • submit to reddit

We all know the Java platform allows us to create reusable objects in memory. However, all of those objects exist only as long as the Java virtual machine remains running. It would be nice if the objects we create could exist beyond the lifetime of the virtual machine. Well, with object serialization, you can flatten your objects and reuse them in powerful ways.

Object serialization is the process of saving an object’s state to a sequence of bytes, as well as the process of rebuilding those bytes into a live object at some future time. The Java Serialization API provides a standard mechanism for developers to handle object serialization. The API is small and easy to use, provided the classes and methods are understood.

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.


References

http://java.sun.com/developer/technicalArticles/Programming/serialization
http://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html
http://docs.oracle.com/javase/6/docs/api/java/io/Externalizable.html

 

From http://singztechmusings.in/marshalling-unmarshalling-java-objects-serialization-vs-externalization/

Published at DZone with permission of Singaram Subramanian, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Dapeng Liu replied on Wed, 2012/02/01 - 2:06am

Externalization is needed when the storage space is very constrained, such as http cookie

Kieron Wilkinson replied on Wed, 2012/02/01 - 7:38am

Externalizable is also useful for managing changes to objects, so that old versions of objects can be de-serialised with new classes that would otherwise have been incompatible using Serializable+reflection. Definitely still useful.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.