This question already has an answer here:
-
What is a serialVersionUID and why should I use it?
24 answers
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.
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.
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
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.
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.
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.