Serialization in Java – Java Serialization

Filed Under: Java

Serialization in Java was introduced in JDK 1.1 and it is one of the important feature of Core Java.

Serialization in Java

serialization in java, java serialization, what is serialization in java, serializable in java

Serialization in Java allows us to convert an Object to stream that we can send over the network or save it as file or store in DB for later usage. Deserialization is the process of converting Object stream to actual Java Object to be used in our program. Serialization in Java seems very easy to use at first but it comes with some trivial security and integrity issues that we will look in the later part of this article. We will look into following topics in this tutorial.

  1. Serializable in Java
  2. Class Refactoring with Serialization and serialVersionUID
  3. Java Externalizable Interface
  4. Java Serialization Methods
  5. Serialization with Inheritance
  6. Serialization Proxy Pattern

Serializable in Java

If you want a class object to be serializable, all you need to do it implement the java.io.Serializable interface. Serializable in java is a marker interface and has no fields or methods to implement. It’s like an Opt-In process through which we make our classes serializable.

Serialization in java is implemented by ObjectInputStream and ObjectOutputStream, so all we need is a wrapper over them to either save it to file or send it over the network. Let’s see a simple Serialization in java program example.


package com.journaldev.serialization;

import java.io.Serializable;

public class Employee implements Serializable {

//	private static final long serialVersionUID = -6470090944414208496L;
	
	private String name;
	private int id;
	transient private int salary;
//	private String password;
	
	@Override
	public String toString(){
		return "Employee{name="+name+",id="+id+",salary="+salary+"}";
	}
	
	//getter and setter methods
	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

	public int getSalary() {
		return salary;
	}

	public void setSalary(int salary) {
		this.salary = salary;
	}

//	public String getPassword() {
//		return password;
//	}
//
//	public void setPassword(String password) {
//		this.password = password;
//	}
	
}

Notice that it’s a simple java bean with some properties and getter-setter methods. If you want an object property to be not serialized to stream, you can use transient keyword like I have done with salary variable.

Now suppose we want to write our objects to file and then deserialize it from the same file. So we need utility methods that will use ObjectInputStream and ObjectOutputStream for serialization purposes.


package com.journaldev.serialization;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

/**
 * A simple class with generic serialize and deserialize method implementations
 * 
 * @author pankaj
 * 
 */
public class SerializationUtil {

	// deserialize to Object from given file
	public static Object deserialize(String fileName) throws IOException,
			ClassNotFoundException {
		FileInputStream fis = new FileInputStream(fileName);
		ObjectInputStream ois = new ObjectInputStream(fis);
		Object obj = ois.readObject();
		ois.close();
		return obj;
	}

	// serialize the given object and save it to file
	public static void serialize(Object obj, String fileName)
			throws IOException {
		FileOutputStream fos = new FileOutputStream(fileName);
		ObjectOutputStream oos = new ObjectOutputStream(fos);
		oos.writeObject(obj);

		fos.close();
	}

}

Notice that the method arguments work with Object that is the base class of any java object. It’s written in this way to be generic in nature.

Now let’s write a test program to see Java Serialization in action.


package com.journaldev.serialization;

import java.io.IOException;

public class SerializationTest {
	
	public static void main(String[] args) {
		String fileName="employee.ser";
		Employee emp = new Employee();
		emp.setId(100);
		emp.setName("Pankaj");
		emp.setSalary(5000);
		
		//serialize to file
		try {
			SerializationUtil.serialize(emp, fileName);
		} catch (IOException e) {
			e.printStackTrace();
			return;
		}
		
		Employee empNew = null;
		try {
			empNew = (Employee) SerializationUtil.deserialize(fileName);
		} catch (ClassNotFoundException | IOException e) {
			e.printStackTrace();
		}
		
		System.out.println("emp Object::"+emp);
		System.out.println("empNew Object::"+empNew);
	}
}

When we run above test program for serialization in java, we get following output.


emp Object::Employee{name=Pankaj,id=100,salary=5000}
empNew Object::Employee{name=Pankaj,id=100,salary=0}

Since salary is a transient variable, it’s value was not saved to file and hence not retrieved in the new object. Similarly static variable values are also not serialized since they belongs to class and not object.

Class Refactoring with Serialization and serialVersionUID

Serialization in java permits some changes in the java class if they can be ignored. Some of the changes in class that will not affect the deserialization process are:

  • Adding new variables to the class
  • Changing the variables from transient to non-transient, for serialization it’s like having a new field.
  • Changing the variable from static to non-static, for serialization it’s like having a new field.

But for all these changes to work, the java class should have serialVersionUID defined for the class. Let’s write a test class just for deserialization of the already serialized file from previous test class.


package com.journaldev.serialization;

import java.io.IOException;

public class DeserializationTest {

	public static void main(String[] args) {

		String fileName="employee.ser";
		Employee empNew = null;
		
		try {
			empNew = (Employee) SerializationUtil.deserialize(fileName);
		} catch (ClassNotFoundException | IOException e) {
			e.printStackTrace();
		}
		
		System.out.println("empNew Object::"+empNew);
		
	}
}

Now uncomment the “password” variable and it’s getter-setter methods from Employee class and run it. You will get below exception;


java.io.InvalidClassException: com.journaldev.serialization.Employee; local class incompatible: stream classdesc serialVersionUID = -6470090944414208496, local class serialVersionUID = -6234198221249432383
	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:604)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1601)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
	at com.journaldev.serialization.SerializationUtil.deserialize(SerializationUtil.java:22)
	at com.journaldev.serialization.DeserializationTest.main(DeserializationTest.java:13)
empNew Object::null

The reason is clear that serialVersionUID of the previous class and new class are different. Actually if the class doesn’t define serialVersionUID, it’s getting calculated automatically and assigned to the class. Java uses class variables, methods, class name, package etc to generate this unique long number. If you are working with any IDE, you will automatically get a warning that “The serializable class Employee does not declare a static final serialVersionUID field of type long”.

We can use java utility “serialver” to generate the class serialVersionUID, for Employee class we can run it with below command.


SerializationExample/bin$serialver -classpath . com.journaldev.serialization.Employee

Note that it’s not required that the serial version is generated from this program itself, we can assign this value as we want. It just need to be there to let deserialization process know that the new class is the new version of the same class and should be deserialized of possible.

For example, uncomment only the serialVersionUID field from the Employee class and run SerializationTest program. Now uncomment the password field from Employee class and run the DeserializationTest program and you will see that the object stream is deserialized successfully because the change in Employee class is compatible with serialization process.

Java Externalizable Interface

If you notice the java serialization process, it’s done automatically. Sometimes we want to obscure the object data to maintain it’s integrity. We can do this by implementing java.io.Externalizable interface and provide implementation of writeExternal() and readExternal() methods to be used in serialization process.


package com.journaldev.externalization;

import java.io.Externalizable;
import java.io.IOException;
import java.io.ObjectInput;
import java.io.ObjectOutput;

public class Person implements Externalizable{

	private int id;
	private String name;
	private String gender;
	
	@Override
	public void writeExternal(ObjectOutput out) throws IOException {
		out.writeInt(id);
		out.writeObject(name+"xyz");
		out.writeObject("abc"+gender);
	}

	@Override
	public void readExternal(ObjectInput in) throws IOException,
			ClassNotFoundException {
		id=in.readInt();
		//read in the same order as written
		name=(String) in.readObject();
		if(!name.endsWith("xyz")) throw new IOException("corrupted data");
		name=name.substring(0, name.length()-3);
		gender=(String) in.readObject();
		if(!gender.startsWith("abc")) throw new IOException("corrupted data");
		gender=gender.substring(3);
	}

	@Override
	public String toString(){
		return "Person{id="+id+",name="+name+",gender="+gender+"}";
	}
	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getGender() {
		return gender;
	}

	public void setGender(String gender) {
		this.gender = gender;
	}

}

Notice that I have changed the field values before converting it to Stream and then while reading reversed the changes. In this way, we can maintain data integrity of some sorts. We can throw exception if after reading the stream data, the integrity checks fail. Let’s write a test program to see it in action.


package com.journaldev.externalization;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class ExternalizationTest {

	public static void main(String[] args) {
		
		String fileName = "person.ser";
		Person person = new Person();
		person.setId(1);
		person.setName("Pankaj");
		person.setGender("Male");
		
		try {
			FileOutputStream fos = new FileOutputStream(fileName);
			ObjectOutputStream oos = new ObjectOutputStream(fos);
		    oos.writeObject(person);
		    oos.close();
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
		FileInputStream fis;
		try {
			fis = new FileInputStream(fileName);
			ObjectInputStream ois = new ObjectInputStream(fis);
		    Person p = (Person)ois.readObject();
		    ois.close();
		    System.out.println("Person Object Read="+p);
		} catch (IOException | ClassNotFoundException e) {
			e.printStackTrace();
		}
	    
	}
}

When we run above program, we get following output.


Person Object Read=Person{id=1,name=Pankaj,gender=Male}

So which one is better to be used for serialization in java. Actually it’s better to use Serializable interface and by the time we reach at the end of article, you will know why.

Java Serialization Methods

We have seen that serialization in java is automatic and all we need is implementing Serializable interface. The implementation is present in the ObjectInputStream and ObjectOutputStream classes. But what if we want to change the way we are saving data, for example we have some sensitive information in the object and before saving/retrieving we want to encrypt/decrypt it. That’s why there are four methods that we can provide in the class to change the serialization behavior.

If these methods are present in the class, they are used for serialization purposes.

  1. readObject(ObjectInputStream ois): If this method is present in the class, ObjectInputStream readObject() method will use this method for reading the object from stream.
  2. writeObject(ObjectOutputStream oos): If this method is present in the class, ObjectOutputStream writeObject() method will use this method for writing the object to stream. One of the common usage is to obscure the object variables to maintain data integrity.
  3. Object writeReplace(): If this method is present, then after serialization process this method is called and the object returned is serialized to the stream.
  4. Object readResolve(): If this method is present, then after deserialization process, this method is called to return the final object to the caller program. One of the usage of this method is to implement Singleton pattern with Serialized classes. Read more at Serialization and Singleton.

Usually while implementing above methods, it’s kept as private so that subclasses can’t override them. They are meant for serialization purpose only and keeping them private avoids any security issue.

Serialization with Inheritance

Sometimes we need to extend a class that doesn’t implement Serializable interface. If we rely on the automatic serialization behavior and the superclass has some state, then they will not be converted to stream and hence not retrieved later on.

This is one place, where readObject() and writeObject() methods really help. By providing their implementation, we can save the super class state to the stream and then retrieve it later on. Let’s see this in action.


package com.journaldev.serialization.inheritance;

public class SuperClass {

	private int id;
	private String value;
	
	public int getId() {
		return id;
	}
	public void setId(int id) {
		this.id = id;
	}
	public String getValue() {
		return value;
	}
	public void setValue(String value) {
		this.value = value;
	}	
}

SuperClass is a simple java bean but it’s not implementing Serializable interface.


package com.journaldev.serialization.inheritance;

import java.io.IOException;
import java.io.InvalidObjectException;
import java.io.ObjectInputStream;
import java.io.ObjectInputValidation;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class SubClass extends SuperClass implements Serializable, ObjectInputValidation{

	private static final long serialVersionUID = -1322322139926390329L;

	private String name;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
	
	@Override
	public String toString(){
		return "SubClass{id="+getId()+",value="+getValue()+",name="+getName()+"}";
	}
	
	//adding helper method for serialization to save/initialize super class state
	private void readObject(ObjectInputStream ois) throws ClassNotFoundException, IOException{
		ois.defaultReadObject();
		
		//notice the order of read and write should be same
		setId(ois.readInt());
		setValue((String) ois.readObject());	
	}
	
	private void writeObject(ObjectOutputStream oos) throws IOException{
		oos.defaultWriteObject();
		
		oos.writeInt(getId());
		oos.writeObject(getValue());
	}

	@Override
	public void validateObject() throws InvalidObjectException {
		//validate the object here
		if(name == null || "".equals(name)) throw new InvalidObjectException("name can't be null or empty");
		if(getId() <=0) throw new InvalidObjectException("ID can't be negative or zero");
	}	
}

Notice that order of writing and reading the extra data to the stream should be same. We can put some logic in reading and writing data to make it secure.

Also notice that the class is implementing ObjectInputValidation interface. By implementing validateObject() method, we can put some business validations to make sure that the data integrity is not harmed.

Let’s write a test class and see if we can retrieve the super class state from serialized data or not.


package com.journaldev.serialization.inheritance;

import java.io.IOException;

import com.journaldev.serialization.SerializationUtil;

public class InheritanceSerializationTest {

	public static void main(String[] args) {
		String fileName = "subclass.ser";
		
		SubClass subClass = new SubClass();
		subClass.setId(10);
		subClass.setValue("Data");
		subClass.setName("Pankaj");
		
		try {
			SerializationUtil.serialize(subClass, fileName);
		} catch (IOException e) {
			e.printStackTrace();
			return;
		}
		
		try {
			SubClass subNew = (SubClass) SerializationUtil.deserialize(fileName);
			System.out.println("SubClass read = "+subNew);
		} catch (ClassNotFoundException | IOException e) {
			e.printStackTrace();
		}
	}
}

When we run above class, we get following output.


SubClass read = SubClass{id=10,value=Data,name=Pankaj}

So in this way, we can serialize super class state even though it’s not implementing Serializable interface. This strategy comes handy when the super class is a third-party class that we can’t change.

Serialization Proxy Pattern

Serialization in java comes with some serious pitfalls such as;

  • The class structure can’t be changed a lot without breaking the java serialization process. So even though we don’t need some variables later on, we need to keep them just for backward compatibility.
  • Serialization causes huge security risks, an attacker can change the stream sequence and cause harm to the system. For example, user role is serialized and an attacker change the stream value to make it admin and run malicious code.

Java Serialization Proxy pattern is a way to achieve greater security with Serialization. In this pattern, an inner private static class is used as a proxy class for serialization purpose. This class is designed in the way to maintain the state of the main class. This pattern is implemented by properly implementing readResolve() and writeReplace() methods.

Let us first write a class which implements serialization proxy pattern and then we will analyze it for better understanding.


package com.journaldev.serialization.proxy;

import java.io.InvalidObjectException;
import java.io.ObjectInputStream;
import java.io.Serializable;

public class Data implements Serializable{

	private static final long serialVersionUID = 2087368867376448459L;

	private String data;
	
	public Data(String d){
		this.data=d;
	}

	public String getData() {
		return data;
	}

	public void setData(String data) {
		this.data = data;
	}
	
	@Override
	public String toString(){
		return "Data{data="+data+"}";
	}
	
	//serialization proxy class
	private static class DataProxy implements Serializable{
	
		private static final long serialVersionUID = 8333905273185436744L;
		
		private String dataProxy;
		private static final String PREFIX = "ABC";
		private static final String SUFFIX = "DEFG";
		
		public DataProxy(Data d){
			//obscuring data for security
			this.dataProxy = PREFIX + d.data + SUFFIX;
		}
		
		private Object readResolve() throws InvalidObjectException {
			if(dataProxy.startsWith(PREFIX) && dataProxy.endsWith(SUFFIX)){
			return new Data(dataProxy.substring(3, dataProxy.length() -4));
			}else throw new InvalidObjectException("data corrupted");
		}
		
	}
	
	//replacing serialized object to DataProxy object
	private Object writeReplace(){
		return new DataProxy(this);
	}
	
	private void readObject(ObjectInputStream ois) throws InvalidObjectException{
		throw new InvalidObjectException("Proxy is not used, something fishy");
	}
}
  • Both Data and DataProxy class should implement Serializable interface.
  • DataProxy should be able to maintain the state of Data object.
  • DataProxy is inner private static class, so that other classes can’t access it.
  • DataProxy should have a single constructor that takes Data as argument.
  • Data class should provide writeReplace() method returning DataProxy instance. So when Data object is serialized, the returned stream is of DataProxy class. However DataProxy class is not visible outside, so it can’t be used directly.
  • DataProxy class should implement readResolve() method returning Data object. So when Data class is deserialized, internally DataProxy is deserialized and when it’s readResolve() method is called, we get Data object.
  • Finally implement readObject() method in Data class and throw InvalidObjectException to avoid hackers attack trying to fabricate Data object stream and parse it.

Let’s write a small test to check whether implementation works or not.


package com.journaldev.serialization.proxy;

import java.io.IOException;

import com.journaldev.serialization.SerializationUtil;

public class SerializationProxyTest {

	public static void main(String[] args) {
		String fileName = "data.ser";
		
		Data data = new Data("Pankaj");
		
		try {
			SerializationUtil.serialize(data, fileName);
		} catch (IOException e) {
			e.printStackTrace();
		}
		
		try {
			Data newData = (Data) SerializationUtil.deserialize(fileName);
			System.out.println(newData);
		} catch (ClassNotFoundException | IOException e) {
			e.printStackTrace();
		}
	}

}

When we run above class, we get below output in console.


Data{data=Pankaj}

If you will open the data.ser file, you can see that DataProxy object is saved as stream in the file.

That’s all for Serialization in Java, it looks simple but we should use it judiciously and it’s always better not to rely on default implementation. Download the project from above link and play around with it to learn more.

Comments

  1. Vinayak A says:

    Hi Pankaj,

    ObjectOutputStream and ObjectInputStream implement the Autocloseable interface, then why we explicitly closing these two streams in the code.?

    Could you please help?

  2. Vikash says:

    Nice and very informative article, some points i want to highlight ..

    1. HashCode can be overridden and you can force that to be equal if objects are equal in state(attributes).

    2. But even that cant solve the problem as in memory there would be two instances of singleton, even after that.(changing state of one wont change the another)

  3. skadam says:

    Hi,

    If I provide the multiple objects with same serialization id, then how objects will
    de-serialized which multiple objects as same serialization id? . Could you please clarify on this question.

    Thanks,

  4. Externalizor is an open source java library which focus on providing an efficient Externalizable implementation. It is much faster than the default JAVA serialization. The generated binary is smaller by a factor of 100 compared to default JAVA serialization

  5. apple says:

    how to run these codes in command prompt??

  6. Basha says:

    Hi pankaj,

    I have one question for why Java Object class doesnt implements Serializable interface, what is the reason for this. could you please give me a explanation.

    1. Mujahid Khan says:

      If serialization were in object class,how would you turn it off? Interface indicate functionality,not a lack of functionality, So the model of polymorphism wouldn’t work.

  7. Ravi Jain says:

    One thing that is not mentioned in this article is class implementing Externalizable interface must have default constructor.

  8. Lalatendu says:

    Hi Pankaj
    Thanks a lot. All your blog posts are really nice. . Could you please clarify me as ObjectOutputStream and ObjectInputStream implement the Autocloseable interface, then why we explicitly closing these two streams in the code.

  9. Kartik says:

    I think, In the first paragraph you have used the word Synchronization instead of Serialization.
    “Java Synchronization process seems very easy….”

    Right?

    1. Pankaj says:

      Yes, thanks for pointing it out. I have corrected it.

  10. Mohammad Nawazish Khan says:

    Hi Pankaj, it has always been great learning experience reading your blog posts. But of late an aspect of Serialization has been troubling me which led me to this post. However the blog content with regards to serializing a class instance with inheritance hierarchy is not consistent with the actual result that we get.

    You say that “Sometimes we need to extend a class that doesn’t implement Serializable interface. If we rely on the automatic serialization behavior and the superclass has some state, then they will not be converted to stream and hence not retrieved later on.” But I run the following code and it does serializes and deserializes the non serializable super type quite ok!! That is without any extra effort of implementing any special method – writeObject (…), readObject (…) in the serializable sub class.


    public class SerializingSuperClassDemo {

    public static void main(String[] args) throws IOException, ClassNotFoundException {
    SubClass sub = new SubClass ();
    ObjectOutputStream oos = StreamUtility.returnOOS("C:\CoreCode\SuperSerialize.mnk");
    oos.writeObject(sub);
    oos.close();

    ObjectInputStream ois = StreamUtility.returnreOIS("C:\CoreCode\SuperSerialize.mnk");
    sub = (SubClass)ois.readObject();
    System.out.println(sub);
    }

    }

    class SuperClass {
    int supInt = 1;
    }

    class SubClass extends SuperClass implements java.io.Serializable {
    int subInt = 0;

    @Override
    public String toString (){
    return supInt+" "+subInt;
    }
    }

    And here is the StreamUtility class:


    public class StreamUtility {
    public static ObjectOutputStream returnOOS(String fileName){
    ObjectOutputStream oos = null;
    try {
    FileOutputStream fos = new FileOutputStream (fileName);
    oos = new ObjectOutputStream (fos);
    } catch (FileNotFoundException ex) {
    Logger.getLogger(StreamUtility.class.getName()).log(Level.SEVERE, null, ex);
    } catch (IOException ex) {
    Logger.getLogger(StreamUtility.class.getName()).log(Level.SEVERE, null, ex);
    }
    return oos;
    }

    public static ObjectInputStream returnreOIS (String fileName){
    ObjectInputStream ois = null;
    try {
    FileInputStream fis = new FileInputStream (fileName);
    ois = new ObjectInputStream (fis);

    } catch (FileNotFoundException ex) {
    Logger.getLogger(StreamUtility.class.getName()).log(Level.SEVERE, null, ex);
    } catch (IOException ex) {
    Logger.getLogger(StreamUtility.class.getName()).log(Level.SEVERE, null, ex);
    }
    return ois;
    }

    }


    And here is the output
    1 0

    Could you kindly explain how was 1 read and deserialized when non serializable super type fields aren’t serialized. I would anxiously wait to read your reply.

    1. Pankaj says:

      There is a flaw in your code, super class value is not changing. From below code;

      package com.journaldev.utils;
      
      import java.io.IOException;
      import java.io.ObjectInputStream;
      import java.io.ObjectOutputStream;
      
      public class SerializingSuperClassDemo {
      
      	public static void main(String[] args) throws IOException,
      			ClassNotFoundException {
      		SubClass sub = new SubClass();
      		sub.setSubInt(10);
      		sub.setSupInt(10);
      		ObjectOutputStream oos = StreamUtility
      				.returnOOS("SuperSerialize.mnk");
      		oos.writeObject(sub);
      		oos.close();
      
      		ObjectInputStream ois = StreamUtility
      				.returnreOIS("SuperSerialize.mnk");
      		sub = (SubClass) ois.readObject();
      		System.out.println(sub);
      	}
      
      }
      
      class SuperClass {
      	private int supInt;
      
      	public int getSupInt() {
      		return supInt;
      	}
      
      	public void setSupInt(int supInt) {
      		this.supInt = supInt;
      	}
      	
      	
      }
      
      class SubClass extends SuperClass implements java.io.Serializable {
      	private static final long serialVersionUID = 7157836599169166115L;
      	private int subInt;
      
      	@Override
      	public String toString() {
      		return getSupInt() + " " + getSubInt();
      	}
      
      	public int getSubInt() {
      		return subInt;
      	}
      
      	public void setSubInt(int subInt) {
      		this.subInt = subInt;
      	}
      }
      

      Output is 0 10 proving what I mentioned in the blog post.

      1. Mohammad Nawazish Khan says:

        Why did our results vary since what I observe is that you have added setters-getters for fields and provided serialVersionUID for the subclass. How and why should that make any difference since setters-getters does not matter and any way serialVersionUID is evaluated and added by serialization runtime. That is why what is the flaw you saw in my code? Does initializing fields an issue with serialization and the way SubClass constructor is called during de-serialization from input stream?

        1. Pankaj says:

          You are using default value in super class.

          1. Mohammad Nawazish Khan says:

            What I understand by “default” value is the value that Java compiler provides to non initialized member fields, however, in my case I do not think I used default value – I initialized it with value 10 (integer type). The default value that compiler offers should have been 0 which is not the case.

            I could not find any java document which declares that default serialization behavior would fail if a member field is initialized.

            Could you please throw some light.

        2. Dheeraj Bansal says:

          Can you tell me how to create own serialization in java?

        3. SK says:

          supInt is of type Java Integer which is ultimately Serializable. And you have declared it as public so it’s automatically part of Subclass that’s why you are getting its value as 1. Pankaj has now restricted access to private so it’s not part of SubClass.

          One more thing, if you have any other object (like Employee object instead of primitive supInt) which is not of type Serializable then it won’t take part in serialization.

  11. md farooq says:

    good explanation, covered many things from serialization.

  12. ET says:

    Very nice post this one!

  13. Sharanabasava says:

    Really nice one. Thanks a lot. Can you explain me oops concept with example.

  14. Siddheshwar says:

    Its Awesome. Simply great.

  15. Nikos says:

    Thank you very much for your help!!!

  16. Shubham Srivastava says:

    If the class doesn’t define serialVersionUID, it’s getting calculated automatically by java compiler and assigned to the class as a private variable.

    1. Swapnil says:

      Really nice fully covered article on java serialization..thanks a lot

  17. Mufim says:

    Please explain public vs private vs protected serialversionUID.Since we have to make unique serialversionUID why it is not private by default

    1. Mohammad Nawazish Khan says:

      API does not restrict you from assigning serialVersionUID as private or protected or package private for that matter. You may do it if you need.

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages