Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

November Discount Launch 2022 – Top
We’re finally running a Black Friday launch. All Courses are 30% off until the end of this week:


November Discount Launch 2022 – TEMP TOP (NPI)
We’re finally running a Black Friday launch. All Courses are 30% off until the end of this week:


1. Overview

The serialVersionUID attribute is an identifier that is used to serialize/deserialize an object of a Serializable class.

In this quick tutorial, we'll discuss what is serialVersionUID and how to use it through examples.

2. Serial Version UID

Simply put, we use the serialVersionUID attribute to remember versions of a Serializable class to verify that a loaded class and the serialized object are compatible.

The serialVersionUID attributes of different classes are independent. Therefore, it is not necessary for different classes to have unique values.

Next, let's learn how to use serialVersionUID through some examples.

Let's start by creating a serializable class and declaring a serialVersionUID identifier:

public class AppleProduct implements Serializable {

    private static final long serialVersionUID = 1234567L;

    public String headphonePort;
    public String thunderboltPort;

Next, we'll need two utility classes: one to serialize an AppleProduct object into a String, and another to deserialize the object from that String:

public class SerializationUtility {

    public static void main(String[] args) {
        AppleProduct macBook = new AppleProduct();
        macBook.headphonePort = "headphonePort2020";
        macBook.thunderboltPort = "thunderboltPort2020";

        String serializedObj = serializeObjectToString(macBook);
        System.out.println("Serialized AppleProduct object to string:");

    public static String serializeObjectToString(Serializable o) {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(baos);
        return Base64.getEncoder().encodeToString(baos.toByteArray());
public class DeserializationUtility {
    public static void main(String[] args) {
        String serializedObj = ... // ommited for clarity
          "Deserializing AppleProduct...");
        AppleProduct deserializedObj = (AppleProduct) deSerializeObjectFromString(
          "Headphone port of AppleProduct:"
            + deserializedObj.getHeadphonePort());
          "Thunderbolt port of AppleProduct:"
           + deserializedObj.getThunderboltPort());
    public static Object deSerializeObjectFromString(String s)
      throws IOException, ClassNotFoundException {
        byte[] data = Base64.getDecoder().decode(s);
        ObjectInputStream ois = new ObjectInputStream(
          new ByteArrayInputStream(data));
        Object o = ois.readObject();
        return o;

We begin by running SerializationUtility.java, which saves (serializes) the AppleProduct object into a String instance, encoding the bytes using Base64.

Then, using that String as an argument for the deserialization method, we run DeserializationUtility.java, which reassembles (deserializes) the AppleProduct object from the given String.

The output generated should be similar to this:

Serialized AppleProduct object to string:
Deserializing AppleProduct...
Headphone port of AppleProduct:headphonePort2020
Thunderbolt port of AppleProduct:thunderboltPort2020

Now, let's modify the serialVersionUID constant in AppleProduct.java, and reattempt to deserialize the AppleProduct object from the same String produced earlier. Re-running DeserializationUtility.java should generate this output.

Deserializing AppleProduct...
Exception in thread "main" java.io.InvalidClassException: com.baeldung.deserialization.AppleProduct; local class incompatible: stream classdesc serialVersionUID = 1234567, local class serialVersionUID = 7654321
	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1630)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1521)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1781)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1353)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:373)
	at com.baeldung.deserialization.DeserializationUtility.deSerializeObjectFromString(DeserializationUtility.java:24)
	at com.baeldung.deserialization.DeserializationUtility.main(DeserializationUtility.java:15)

By changing the serialVersionUID of the class, we modified its version/state. As a result, no compatible classes were found during deserialization, and an InvalidClassException was thrown.

If serialVersionUID is not provided in a Serializable class, the JVM will generate one automatically. However, it is good practice to provide the serialVersionUID value and update it after changes to the class so that we can have control over the serialization/deserialization process. We'll take a closer look at it in a later section.

3. Compatible Changes

Let's say we need to add a new field lightningPort to our existing AppleProduct class:

public class AppleProduct implements Serializable {
    public String lightningPort;

Since we are just adding a new field, no change in the serialVersionUID will be required. This is because, during the deserialization process, null will be assigned as the default value for the lightningPort field.

Let's modify our DeserializationUtility class to print the value of this new field:

System.out.println("LightningPort port of AppleProduct:"
  + deserializedObj.getLightningPort());

Now, when we rerun the DeserializationUtility class, we will see output similar to:

Deserializing AppleProduct...
Headphone port of AppleProduct:headphonePort2020
Thunderbolt port of AppleProduct:thunderboltPort2020
Lightning port of AppleProduct:null

4. Default Serial Version

If we don't define a serialVersionUID state for a Serializable class, then Java will define one based on some properties of the class itself such as the class name, instance fields, and so on.

Let's define a simple Serializable class:

public class DefaultSerial implements Serializable {

If we serialize an instance of this class like the following:

DefaultSerial instance = new DefaultSerial();

This will print the Base64 digest of the serialized binary:


Just like before, we should be able to deserialize this instance from the digest:

String digest = "rO0ABXNyACpjb20uYmFlbGR1bmcuZGVzZXJpY" 
  + "WxpemF0aW9uLkRlZmF1bHRTZXJpYWx9iVz3Lz/mdAIAAHhw";
DefaultSerial instance = (DefaultSerial) DeserializationUtility.deSerializeObjectFromString(digest);

However, some changes to this class may break the serialization compatibility. For instance, if we add a private field to this class:

public class DefaultSerial implements Serializable {
    private String name;

And then try to deserialize the same Base64 digest to a class instance, we'll get an InvalidClassException:

Exception in thread "main" java.io.InvalidClassException: 
  com.baeldung.deserialization.DefaultSerial; local class incompatible: 
  stream classdesc serialVersionUID = 9045863543269746292, 
  local class serialVersionUID = -2692722436255640434

Because of this sort of unwanted incompatibility, it's always a good idea to declare a serialVersionUID in Serializable classes. This way we can keep or evolve the version as the class itself evolves.

5. Conclusion

In this quick article, we demonstrated the use of the serialVersionUID constant to facilitate versioning of serialized data.

As always, the code samples used throughout this article can be found over on GitHub.

November Discount Launch 2022 – Bottom
We’re finally running a Black Friday launch. All Courses are 30% off until the end of this week:


Generic footer banner
Comments are closed on this article!