7

I'm creating a Java application, and when creating an interface to use with an ADT, it finds the need to initialize a random number as an ID number.

public class StackFullException extends RuntimeException {
    private static final long serialVersionUID = 1L;
    public StackFullException(){}
    public StackFullException(String message) {
        super(message);
    }
}

I'm curious as to whether leaving this out will impact anything consequential about my program and if so, how to avoid it.

Archibald
  • 456
  • 1
  • 7
  • 20
  • 1
    What you are doing is fine. You don't need anything super random. I often just use the concatenated version number (with revision) as the UID for a class to guarantee uniqueness. – Mad Physicist Feb 04 '14 at 20:25
  • 1
    This has definitely been asked and answered before on SO. Have you searched the archives. – Krish Srinivasan Feb 04 '14 at 20:25
  • 1
    http://stackoverflow.com/questions/5576047/why-does-serialization-require-a-serial-version-uid-in-implemented-class?rq=1 , http://stackoverflow.com/questions/285793/what-is-a-serialversionuid-and-why-should-i-use-it?rq=1 , http://stackoverflow.com/questions/2258676/what-is-serial-version-id-in-java?lq=1 – user2864740 Feb 04 '14 at 20:27
  • 1
    Make sure to search first. Such trivially found duplicated questions should *not* be asked (and should *not* be upvoted when done so). – user2864740 Feb 04 '14 at 20:29

5 Answers5

10

The serialVersionUID is part of the black magic of the Java serialization API.

It is used to uniquely identify a version of the class so that when a class is de-serialized the version can be checked against the version of the class loaded by the ClassLoader.

The serialization API will generate a serialVersionUID itself if none is specified but this is then subject to random change by inconsequential changes (or at least ones that don't break serialization compatibility).

Adding the field yourself gives you control over this process - you decide when a change to the class should break de-serialization of older versions.

More information can be found in the JavaDocs for Serializable.

In short, if you plan to serialize this class and then de-serialize it later - but after making some changes to code and recompiling etc - this field is more-or-less essential to guarantee that this will work as intended.

Boris the Spider
  • 59,842
  • 6
  • 106
  • 166
2

The Serializable interface gives enough detail in this regard:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value.

Also you can read more about this in Java Object Serialization Specification

Rohit Jain
  • 209,639
  • 45
  • 409
  • 525
1

searialVersionUID is just a version number you place on the interface to know it's communicating with the same API. In other words, if the client's Java Object is "1L" and the server's is "2L" then it will throw a missmatch error.

Matt Westlake
  • 3,499
  • 7
  • 39
  • 80
1

UIDs in this context can also be used to distinguish between two objects being written to disk.

Source: http://www.mkyong.com/java-best-practices/understand-the-serialversionuid/

As others have said, the UID is optional and shouldn't impact your program.

Kyte
  • 834
  • 2
  • 12
  • 27
0

It's used to reflect structural changes to the class when used with the JDK's serialization. It's completely optional to use. Personally, I never create such fields and often delete them when I find them.

evanchooly
  • 6,102
  • 1
  • 16
  • 23
  • 4
    Bad habit, considering that the JVM-generated ID is not guaranteed to be the same on different platforms. You should always define your own ID for serializable classes. – Mad Physicist Feb 04 '14 at 20:22
  • not at all. i don't use the JDK serialization because it's fragile and horribly broken. Even Brian Goetz was apologizing for it at devoxx. I use libraries like jackson or xstream which don't rely on such hacks. Outside of RMI (haha! who uses that?) there's no reason to use native serialization over some external format. – evanchooly Feb 04 '14 at 20:26