In computing what is meant by binary compatibility?

I read about it in context of serialization/deserialization that this process of serialize/deserialize should be binary compatible. What does it mean in this context? In particular I am interested in understanding the role of binary compatibility in a language like Java that deals with byte code.

This quote is from Effective Java:

When a serializable class is revised, it is important to check that it is possible to serialize an instance in the new release and deserialize it in old releases, and vice versa. The amount of testing required is thus proportional to the product of the number of serializable classes and the number of releases, which can be large. These tests cannot be con-structed automatically because, in addition to binary compatibility, you must test forsemantic compatibility. In other words, you must ensure both that the serialization-deserialization process succeeds and that it results in a faithful replica of the original object. The greater the change to a serializable class, the greater the need for testing. The need is reduced if a custom serialized form is carefully designed when the class is first written (Items 75, 78), but it does not vanish entirely.


It just means the deserializer has to use the same binary format as the serializer did. For example, consider serializing a string. There are several different binary formats for a string, even though they represent the same data semantically. One way is to first serialize a number representing the length of the string, then write the individual characters. Another way is to just write out the characters and use a null character to signal the end of the string.

One serializer could use 16 bits to represent the length and one could use 32. If it's a unicode string, one serializer could use UTF-8 encoding, one could use UTF-16 encoding, and one could write out a field specifying which encoding it is using in that particular instance.

That's just something as simple and commonplace as a string. When you get to the object layer and higher, there are many more variations for how you can represent something in a binary stream. If your serializer and deserializer aren't binary compatible, you'll get garbage out when you try to deserialize.

Sometimes the binary format will change over time, so a deserializer has to be aware of all previous formats in order to remain backwards compatible. Serialized formats often include a version field for this express purpose.

  • 4
    Big endian and little endian also play into this. – cschneid Jun 12 '13 at 16:22
  • @cschneid What role do they play ? – Geek Jun 12 '13 at 17:40
  • 2
    @Geek If you try serializing a 32 bit integer with a value of decimal 10 on a big endian machine by simply writing out the value in memory, you get x'0000000a' but on a little endian machine you get x'0a000000'. If you want your serialization to be binary compatible across these different architectures you must have a mechanism to deal with the differences. For example, you could choose to not store the in-memory representation but some character representation like "+10". – cschneid Jun 12 '13 at 18:36
  • @cschneid excellent..Why don't you embellish the answer with your point. It is an extremely valid point since without taking this into account binary compatibility will fall flat. – Geek Jun 12 '13 at 18:41
  • @cschneid: I think Java's virtual machine is big endian, even when running on a little endian machine. So, I'm not sure the endian-ness of a machine will impact Java serialization. – Brian Jun 12 '13 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.