Does serialization in java make it platform independent?

Question

Since "Serialization in Java is a mechanism of writing the state of an object into a byte-stream and Deserialization is vice versa of this". So it got me thinking that is it Serialization that makes Java platform independent?

Answer 1

Serialization/deserialization is about data moving in and out of your running program. At this point, because your program is already running, platform dependence/independence has already happened.

Platform independence happens because of compilation of a Java program to a bytecode format. This bytecode is same for all platforms which is then executed by a platform dependent engine. The platform dependent engine/runtime is installed on your machine when you install the JVM/JRE. So the Java code goes:

Java code -> Bytecode -> platform dependent runtime

Answer 2

Nope.

What makes Java platform-independent is the existence of Java-compatible runtimes on many different platforms. More specifically, the existence of Java runtimes for your platform of choice that are capable of executing Java bytecode, the common intermediate language that the Java compiler outputs.

What Serialization/Deserialization does is give you a platform-independent way of communicating between different systems. All you need is serialization/deserialization software on each system that speaks the same communication protocol. Using Java on each side is not required.

Answer 3

I'd say that, at one level, for Java to be platform independent, a built-in serialisation technology (such as it has) is an essential component. There's no point having portable applications unless their data is also portable, which is what a standardised serialisation achieves.

Platform Dependence

I'll now go down a rabit hole of a discussion, where I may be being too pedanctic on what true platform independence really means!

Where things go a bit wrong with Java I think is that (like a lot of other languages) the serialisation is code-first; you decorate or otherwise annotate the source code for a class to indicate how (or if) it should be serialisable. That's fine, but then the Java language is what I call closed; it's difficult or at least inconvenient for a Java application's data to be portable to all other languages. They have to develop equivalent classes, even if there is library support (e.g. an XML library) to navitgate the data. If you have a bunch of data serialised this way, and later it has to be accessible in, say, C, some developer has a lot of work to do!

Also, if you're wanting to change a class in some way, the change has also to be folded into the C source code to. This is a recipe for confusion, duplicate work and error, and no one single implementation (your Java, their C code) is "the one source of truth" as to what the data should be. This then generates the need for things like Interface Control Documents, which become a nightmare to maintain, adhere to, etc.

True Platform Independence?

A more flexible approach is schema-first - where data is described in a language independent way - and language-specific classes' source code generated from it. This is what one does with things like Google Protocol Buffers, ASN.1 (unless one is using the Python libs which have made it code-first again), dBus.

Does it Really Matter?

Possibly not. Whether or not the "closed" nature of built in code-first serialisation matters or not is a project by project matter. Some can be written in all Java, some not. The attraction of using schema-first serialisation is that, if one is uncertain as to what must be able to read data, the schema makes it easy if language / platorm interop become a requirement later on. And it's noticable how often interop does emerge as a requirement.

Summary

So I'd argue that Java alone is not completely platform independent, because it encourages non-portable data definitions, (if by "platform independent" one includes other languages).