Short story about serialization
After many years of hard work, Earth's scientists developed a robot who can help them in daily work. But this robot had fewer features than the robots developed by the scientists from planet Mars.
After a meeting between both planets' scientists, it is decided that Mars will send their robots to Earth. But a problem occurred. The cost of sending 100 robots to Earth was $100 million. And it takes around 60 days of traveling.
Finally, Mars' scientists decided to share their secret with Earth's scientists. This secret was about the structure of class/robot. Earth's scientists developed the same structure on Earth itself. Mars' scientists serialized the data of each robot and sent it to earth. Earth's scientists deserialized the data and fed it into each robot accordingly.
This process saved them time in communicating a massive amount of data.
Some of the robots were being used in some defensive work on Mars. So their scientists marked some crucial properties of those robots as transient before sending their data to Earth. Note that the transient property is set to null (in case of reference) or to the default value (in case of the primitive type) when the object gets deserialized.
One more point noticed by Earth's scientists is that Mars' scientists asked them to create some static variables to keep details about the environment. These details are used by some robots. But Mars' scientists don't share these details. Because Earth's environment was different from Mars' environment.
Even though knowing about the robot class structure and having serialized data Earth's scientist were not able to deserialize the data which can make robots working.
Exception in thread "main" java.io.InvalidClassException:
SerializeMe; local class incompatible: stream classdesc
:
Mars' scientists were waiting for the complete payment. Once the payment was done Mars' scientists shared the serialversionUID with Earth's scientists. Earth's scientist set it to robot class and everything started working.
Update
Though with the help of serialization, they became able to send data using signals instead of actual spaceship, they realized that sending large set of data was still a challenge. Serialization make the process cheaper and faster but it was still slow. Hence the different scientists came up with different ideas to reduce the data size. Some scientists suggested to compress the data and some suggested to use different mechanism to represent it so it can be deserialized back. Some of the ideas are XML, JSON, msgpack, Nimn
Answer from Amit Kumar Gupta on Stack OverflowShort story about serialization
After many years of hard work, Earth's scientists developed a robot who can help them in daily work. But this robot had fewer features than the robots developed by the scientists from planet Mars.
After a meeting between both planets' scientists, it is decided that Mars will send their robots to Earth. But a problem occurred. The cost of sending 100 robots to Earth was $100 million. And it takes around 60 days of traveling.
Finally, Mars' scientists decided to share their secret with Earth's scientists. This secret was about the structure of class/robot. Earth's scientists developed the same structure on Earth itself. Mars' scientists serialized the data of each robot and sent it to earth. Earth's scientists deserialized the data and fed it into each robot accordingly.
This process saved them time in communicating a massive amount of data.
Some of the robots were being used in some defensive work on Mars. So their scientists marked some crucial properties of those robots as transient before sending their data to Earth. Note that the transient property is set to null (in case of reference) or to the default value (in case of the primitive type) when the object gets deserialized.
One more point noticed by Earth's scientists is that Mars' scientists asked them to create some static variables to keep details about the environment. These details are used by some robots. But Mars' scientists don't share these details. Because Earth's environment was different from Mars' environment.
Even though knowing about the robot class structure and having serialized data Earth's scientist were not able to deserialize the data which can make robots working.
Exception in thread "main" java.io.InvalidClassException:
SerializeMe; local class incompatible: stream classdesc
:
Mars' scientists were waiting for the complete payment. Once the payment was done Mars' scientists shared the serialversionUID with Earth's scientists. Earth's scientist set it to robot class and everything started working.
Update
Though with the help of serialization, they became able to send data using signals instead of actual spaceship, they realized that sending large set of data was still a challenge. Serialization make the process cheaper and faster but it was still slow. Hence the different scientists came up with different ideas to reduce the data size. Some scientists suggested to compress the data and some suggested to use different mechanism to represent it so it can be deserialized back. Some of the ideas are XML, JSON, msgpack, Nimn
Serialization is usually used When the need arises to send your data over network or stored in files. By data I mean objects and not text.
Now the problem is your Network infrastructure and your Hard disk are hardware components that understand bits and bytes but not JAVA objects.
Serialization is the translation of your Java object's values/states to bytes to send it over network or save it.
This is analogous to how your voice is transmitted over PSTN telephone lines.
Explain like i'm five - what is Serializable?
Java serialization - advantages and disadvantages, use or avoid? - Software Engineering Stack Exchange
Can someone please help clarify exactly why Serialization is necessary and how it is implemented in Java.
Why should I use kotlinx.serialization?
Videos
Let's define serialization first, then we can talk about why it's so useful.
Serialization is simply turning an existing object into a byte array. This byte array represents the class of the object, the version of the object, and the internal state of the object. This byte array can then be used between JVM's running the same code to transmit/read the object.
Why would we want to do this?
There are several reasons:
Communication: If you have two machines that are running the same code, and they need to communicate, an easy way is for one machine to build an object with information that it would like to transmit, and then serialize that object to the other machine. It's not the best method for communication, but it gets the job done.
Persistence: If you want to store the state of a particular operation in a database, it can be easily serialized to a byte array, and stored in the database for later retrieval.
Deep Copy: If you need an exact replica of an Object, and don't want to go to the trouble of writing your own specialized clone() class, simply serializing the object to a byte array, and then de-serializing it to another object achieves this goal.
Caching: Really just an application of the above, but sometimes an object takes 10 minutes to build, but would only take 10 seconds to de-serialize. So, rather than hold onto the giant object in memory, just cache it out to a file via serialization, and read it in later when it's needed.
Cross JVM Synchronization: Serialization works across different JVMs that may be running on different architectures.
While you're running your application, all of its objects are stored in memory (RAM). When you exit, that memory gets reclaimed by the operating system, and your program essentially 'forgets' everything that happened while it was running. Serialization remedies this by letting your application save objects to disk so it can read them back the next time it starts. If your application is going to provide any way of saving/sharing a previous state, you'll need some form of serialization.
I just don't get it. I'm a junior and see it often in the codebase of the company i work at. Documentation says that it helps serialize and deserialize objects, but why does that need to happen using this interface? There are so many classes that do not implement Serializable, so what happens to them?
Head First Java book says that objects need to be serialized when data is sent over the network or saved to a disk. But there is serialization/deserialization happening to JSON objects for example when they're being sent from server to client and vice versa, and those classes do not implement Serializable.
So in which "special" scenario does one need/want to implement Serializable?
Serialization is mostly used in two areas:
prototyping of persistence
pretty much every object graph can quickly be made serializable, for quick proof-of-concepts or quick-and-dirty applications this might be faster than setting up a real ORM layer or other persistence system
short term storage of almost-arbitrary objects:
Applications servers, for example, have a tendency to persist session information using serialization. This has the advantage that the values in the session can be almost any type (as long as its serializable).
For almost all other uses, the drawbacks you (and the article) mentions are too big: the exact format is hard to keep stable, class changes can easily make your serialized data unreadable, reading/writing the data in non-Java code is almost impossible (or at least a lot harder than necessary).
JAXB and similar technologies provide similar functions with a similarly low cost, while reducing some of the problems.
I use object serialization to allow post-mortem analysis in case of an unexpected error in production. The inputs to a calculation are serialized to a data file. If an error is reported, a simple program can reload the inputs and rerun the calculation with a debugger attached. Or a groovy shell can be used to reload the objects and modify them if desired.
We also use serialization to pass Java objects through HTTP to a web service. Much easier than serializing to and from text. The disadvantage is that the client and server installations must be deployed together, but that's not problem since we control both ends.