February 26, 2017
Hot Topics:

Object Serialization

  • November 7, 2005
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Saving to a Flat File

The first example I will cover is that of using a flat file for object persistence. I define a flat file as a simple file managed by the operating system. This is a very simple concept, so don't get too caught up in this description.

Note: Many people do not like to use the term flat file. The word flat implies that the object is literally flattened, and in a way it is.

One of the things that you may have thought about is the fact that an object cannot be saved to a file like a simple variable—and this is true. In fact, the problem of saving the state of an object has led to a complete software application industry, which I will explain at length later in this article. Normally, when you save a number of variables to a file, you know the order and type of each variable, and then you simply write them out to the file. It could be a comma-delimited file or any other protocol that you may determine.

The problem with an object is that it is not simply a collection of primitive variables. An object can be thought of as an indivisible unit that is composed of a number of parts. Thus, the object must be decomposed into a unit that can be written to a flat file. After the object is decomposed and written to a flat file, there is one major issue left to consider—recomposing the object, basically putting it back together.

Another major problem with storing objects relates to the fact that an object can contain other objects. Consider that a Car object may contain objects like Engines and Wheels. When you save the object to a flat file (or anything else for that matter), you need to save the entire object hierarchy, Car, Engines, and the like.

Java has a built-in mechanism for object persistence. Like other C-based languages, Java largely utilizes the concept of a stream to deal with I/O. To save an object to a file, Java writes it to the file via a Stream. To write to a Stream, objects must implement either the Serializable or Externalizable interface.

Serializing and Marshalling Objects

You have already seen the problem of using objects in environments that were originally designed for structured programming. The middleware example, where you wrote objects to a relational database, is one good example. You also touched on the problem of writing an object to a flat file or sending it over a network.

Basically, to send an object over a wire (for example, to a file, over a network), the system must deconstruct the object (that is, flatten it out), send it over the wire, and then reconstruct it on the other end of the wire. This process is called serializing an object. The act of actually sending the object across a wire is called marshalling an object. A serialized object, in theory, can be written to a flat file and retrieved later, in the same state in which it was written.

The major issue here is that the serialization and de-serialization must use the same specifications. It is sort of like an encryption algorithm. If one object encrypts a string, the object that wants to decrypt it must use the same encryption algorithm. Java provides an interface called Serializable that provides this translation.

Serializing a File

As an example, consider the following code for a class called Person:

import java.util.*;
import java.io.*;
class Person implements Serializable{
   private String name;
   public Person(){
   public Person(String n){
      System.out.println("Inside Person's Constructor");
      name = n;
   String getName() {
      return name;

This is a simple class that contains only a single attribute representing the name of the person.

The item of note here is the line that identifies the class as Serializable. If you actually inspect the Java documentation, you will realize that the Serializable interface really does not contain much; in fact, it is meant solely to identify that the object will be serialized. Below is a short description from the J2SE API specification.

public interface Serializable



You use this Serializable interface to allow you to serialize your Person objects.

class Person implements Serializable {

This Person class also contains a method called getName( ) that returns the name of the object. Other than the Serializable interface, there is really nothing new about this class that you have to consider. Here is where the interesting stuff starts. You now want to write an application that will write this object to a flat file. The application is called SavePerson and is as follows:

import java.util.*;
import java.io.*;
public class SavePerson implements Serializable{
   public static void main(String args[]){
      Person person = new Person("Jack Jones");
         FileOutputStream fos = new FileOutputStream("Name.txt");
         ObjectOutputStream oos = new ObjectOutputStream(fos);
         System.out.print("Person's Name Written: ");
      }  catch(Exception e){

While some of this code delves into some more sophisticated Java code, you can get a general idea of what is happening when an object gets serialized and written to a file.

Although you have not explicitly covered some of the code in this example, like file I/O, you can get into the code in a much great detail with a few of the books referenced at the end of this chapter.

By now you should realize that this is an actual application. How can you tell this? The fact that the code has a main method in it is a sure tip that this is an actual application.

Page 2 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel