We thought that we dedicate a page to share knowledge about various object serialization technologies available and the practical differences among them. We will also discuss various pain-points while switching between the serialized formats. Let us also launch shortly a discussion-forum to discuss on the topics in depth. While it is recommended to post your normal questions in stack-overflow, this forum is dedicated to discuss experiences especially the troubles faced and the outcome enjoyed.

The problem statement

A Web application runs in two computers. 1. The server that has the data and business logic. For example gmail.com 2. A browser running on the client machine. You are reading this on your browser aren’t you?

The data is exchanged between the server and the client on user interactions. For example, the list of emails that fit on a single page (say, a list of 20 emails) is copied from server to client. At server, google uses technology A (such as Java) but on the client side there can be a different technology used (such as JavaScript or an Android App). So, there is a need to exchange the data in a notation that both the server-technology and the client technology is able to interpret received data and compose data to be sent. For example a server can’t send the bytes of a java-object as is because the client may not be able to understand a java-object.

JSON is one of the solutions to the above problem. JSON stands for JavaScriptObjectNotation, but these days its usage is not just limited to JavaScript. ION works in the same ways as that of JSON, but ION is much more efficient when it comes to conversion-speed, size of the transmitted data.

As per the specification, Ion is a richly-typed, self-describing, hierarchical data serialization format. Like JSON, Ion is an alternative to XML. Ion has two formats. The text format is a super-set of JSON with the addition of features intended to meet many more use cases. These additions (the delta from JSON) makes Ion more strongly typed, self-describing/self-typing notation. The binary representation is efficient for persisting, transforming, transmitting and skip-scan-parsing.

Well! Should I really bother to switch to Ion?

Not really ­ **unless ** you are owning a large-scale system and spending a lot of money on hardware just to serialize and serialize JSON (or any other format like XML). At scale, the CPU gains are very attractive.

To put it in short, here is the difference. JSON is human friendly and not so much machine friendly. The notation is platform-independent. Ion is human friendly in text format and machine friendly in binary format. Both the notations are platform-independent.

How painful is it to switch to Ion from JSON?

In short, Ion is an extension of JSON and so the Ion serialization and de-serialization libraries are compatible with JSON. So, you can easily switch from JSON to Ion-text format and then after full-validation your might want to switch to binary format that would start delivering the performance advantages.

Two factors influence the long answer.

There are many libraries available to serialize an object to JSON. Many languages are supported. Usage of Ion is currently limited Java. Python library is going to be available soon.

Ion is 100% backward compatible to JSON. That means, any existing JSON is 100% compliant with Ion. So, if you are talking about Java platform, you can easily move to Ion to take advantage of performance gains in the binary form without compromising on the human-readability aspect.

How do I spell and pronounce Ion?

Ion doesn’t really have a full-form and is spelled as I-o-n (capital I and small ‘o’ and small ‘n’) and pronounced as /ˈʌɪən/. Though Ion is not an abbreviation, it can be remembered as Inter-operable Object Notation.

I want to use Ion. Does it support my language?

Ion is currently available to be used in Java. Let us hope that python and C++ libraries would be released soon.

What additional types does Ion support?

JSON supports string, number, object, array and the primitives true, false and null.

JSON doesn’t support custom types but in Ion you can define your custom-types. Which means, Ion is extensible indefinitely.

Ion supports the following types

  • string – Unicode text literals (eg. “Hello World!”)
  • struct – Unordered collections of tagged values (same as object in JSON)
  • list – Ordered collections of values (same as array in JSON)
  • null – A generic null value
  • bool – Boolean values (eg. true, false, null.bool)
  • int – Signed integers of arbitrary size (eg., 0, -23, 0xBAD, 0b1001). An underscore is allowed to separate digits for the sake of human readability.
  • float – Binary-encoded floating point numbers (IEEE 64-bit). (eg. 1.3e0, 0xFF)
  • decimal – Decimal-encoded real numbers of arbitrary precision (eg. 23., 2.3d1, 0.23d2 (all are equivalent decimal notations))
  • timestamp – Date/time/timezone moments of arbitrary precision (eg. 2016-01-01T00:00-00:00, 2016T, 2016-01-01T00:00-00:00+03:00 // this is with local offset)
  • symbol – identifiers (eg. ‘student name’, studentName, student_name) If symbol has no spaces, single quotes are not required.
  • blob – Binary data of user-defined encoding
  • clob – Text data of user-defined encoding
  • sexp – Ordered collections of values with application-defined semantics

Ion supports custom-types through annotations.

The latest specification of Ion can be viewed at git-hub. However, comparative study of Ion-spec w.r.t JSON is at ion-spec page

The grammar (syntax) of Ion Object format is similar to the grammar of JSON, except the introduction of identifiers, custom-types specified by annotations.

We shall enhance this community based website to include tutorials and links to external content to make this document handy to the developers.

We are a group of technology enthusiasts and this is a community-maintained website to provide quick information on JSON and Ion object serialization formats. This website doesn’t not affiliate to any organization.