Java Serialization vs JSON vs XML

peter picture peter · Jun 19, 2012 · Viewed 25.1k times · Source

I am wondering what serialized mechanism should we choose when dealing with object transferring over the network. What are the pros and cons ?

I know most of the time we use JSON or XML for AJAX since the transfer format are pretty much Javascript format, and plus JSON is pretty lightweight with its small footprint, therefore is Java serialization totally out of the table ?

Answer

Ariel T picture Ariel T · Jun 19, 2012

In general the important question is which client will receive the serialized objects - browsers/JavaScript engines like (node-js), Java client, unknown/multiple clients.

JSON - JSON syntax is basically JavaScript and therefore any component with a JS engine will handle its parsing very well - even complicated data-structures will be converted to "living" objects efficiently. JSON parsers exist for practically any language and it is easy to use even when not using a JS engine, (Take Google Gson for example that is able to convert JSON into corresponding objects with ease) which makes is a good candidate for cross-language communication - for example in a messaging architecture.

XML - Shares many of JSON's benefits - cross-language, lightweight, etc. Adobe Flex for example handles XML very well, even better than JSON. It's definitely an appropriate substitute for JSON. I personally prefer JSON for its JS like syntax, but XML is also good.

Java Serialization - Should be considered only for Java-to-Java communication. An important note is that the class definitions should be on the sending and the receiving ends and often you wouldn't gain much by passing the entire object. I wouldn't rule out RMI as a communication protocol, it does simplify development. However the resulting application components will be hard coupled which will make it very difficult to replace.

One more notes - Serialization in general has its overhead. However when the communication is performed over a network the bottleneck is often the network rather than the serialization/deserialization itself.