Choosing an object serialization format in Scala

Dummi

New Member
I have an application that manages a graph of nodes and arcs, where the nodes have a small number of properties. Now I'm at the point where I need to save out the data, and I need to choose a serialization format. Here's a list of some of the obvious ones, but there may be others I haven't considered.
  • Java Serialization
  • XML
  • JSON
  • Yaml
  • Google protocol buffers
Java serialization is a non-starter for a number of reasons, even in the Java world XML and other serializations formats are preferred for the reasons of interoperability, schema migration, and ease of use.Scala's XML support seems like an obvious choice. However, I personally find the idea of XML literals embedded in source code distasteful (even the creator of the language admits he regrets this decision). This feature perhaps makes more sense when generating marked-up text - but when serializing objects, you really want a higher level API which separates as much as possible the code that understands the internal data structures, from the code that understands the syntax of the serialization format - which means that ideally you should never actually see any XML in your source code. Also, a Google web search reveals a number of blog posts that claim that Scala's XML DOM has lots of warts and is awkward to use. (There are also a number of libraries that claim to improve the situation, but then it becomes a matter of choosing which one.)JSON and Yaml would also work - the issue here is that the most popular serialization libraries are in Java, and so the task involves choosing or writing an appropriate Scala wrapper class. Also, many of these libraries rely on bean reflection, which is possible but somewhat awkward in Scala requiring additional annotations to get things to work.Finally, I've used Google protobufs for a lot of other serialization tasks. The nice part is that the protoc compiler can generate elegant APIs that match the idioms of the target language. However, in this case one of the strengths of protobufs, which is the small size of the encoded data stream, isn't important, and I'd rather have something where the serialized data is human-readable.
 
Back
Top