This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why should I bother about serialVersionUID?
What is SerialVersionUID in serialization in java? What does it do?
From the Javadoc:
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. It is also
strongly advised that explicit serialVersionUID declarations use the
private modifier where possible, since such declarations apply only to
the immediately declaring class--serialVersionUID fields are not
useful as inherited members.
Related
This question already has answers here:
What is a serialVersionUID and why should I use it?
(25 answers)
Closed 7 months ago.
What is private static final long serialVersionUID = 1L in the below code?
public class Authenticator extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
String password = request.getParameter("mypassword");
if(authenticate(username, password)) {
HttpSession session = request.getSession();
session.setAttribute("username",username);
response.sendRedirect("product.jsp");
return;
}
else {
response.sendRedirect("index.jsp");
return;
}
}
}
First, few quick pointers regarding this.
It plays a role during serialization and deserialization. So for the classes e.g. MyCustomRuntimeException where you don't care about serialization, you could ignore it.
If you are using it on classes for serialization purposes but would not store them for any longer durations - more specifically if you would never create a backward incompatible version of that class during this storage, you would not need to change this.
For the use cases where you know you would permanently store it and would create new incompatible version, make sure to increment(uniquely change) it.
From java.io.Serializable
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. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. Array classes cannot declare an explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID values is waived for array classes.
From Joshua Bloch in Effective Java
the automatically generated UID is generated based on a class name, implemented interfaces, and all public and protected members. Changing any of these in any way will change the serialVersionUID. 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 produce different serialVersionUID in different environments. This can result in unexpected InvalidClassException during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier in serialVersionUID where possible, since such declarations apply only to the immediately declaring class.
This question already has answers here:
What is a serialVersionUID and why should I use it?
(25 answers)
Closed 9 years ago.
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.
I have a class say Counter. I serialize Object of this class on JVM-1 in one machine & transfer the serialized Object as a network stream to another machine & deserialize there in JVM-2.
Will this Object get deserialized properly ?
Would there be any error/exception thrown in this case?
Assuming i have compiled the class on both JVMs.
I am assuming that there is no serial Version UID present in the classes
As long as you have the same code/jdk (though different jdks may work) running at both ends, serialization-deserialization would not be a problem.
if you have serialVersionUID in your class, serialize/deserialize will not be a problem, but if serialVersionUID is missing in your code, as you are compiling class with both JVM(I understand, .class file has same content but compiled with different JVMs) in that case, serialVersionUID is assigned by java, which won't be same, hence serialize/deserialize will not work.
So, add
private static final long serialVersionUID = -6903933977591709194L;
in case you haven't added, with any value, and compile as many times, rest assured, serialize/deserialize will work. :)
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 = 11L;
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. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. Array classes cannot declare an explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID values is waived for array classes.
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
This question already has answers here:
What is a serialVersionUID and why should I use it?
(25 answers)
Closed 9 years ago.
Whenever we try to serialize an object of a Class, we always have a unique value for serialVersionId as a private final field, what is its significance with respect to deserialization, can we use it to check whether the object and the values have been deserialized in a proper way ?
It is used to check whether the same class definition was used for Serialization as well as DeSerialization. Straight from the documentation
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. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members.
Also , check Josh Bloch's book Effective Java (2nd Edition):
the automatically-generated UID is generated based on a class name, implemented interfaces, and all public and protected members. Changing any of these in any way will change the serialVersionUID. So you don't need to mess with them only if you are certain that no more than one version of the class will ever be serialized (either across processes or retrieved from storage at a later time).
If you ignore them for now, and find later that you need to change the class in some way but maintain compatibility w/ old version of the class, you can use the JDK tool serialver to generate the serialVersionUID on the old class, and explicitly set that on the new class. (Depending on your changes you may need to also implement custom serialization by adding writeObject and readObject methods - see Serializable javadoc or aforementioned chapter 11.)
From the doc of Serializable Object
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. It is also
strongly advised that explicit serialVersionUID declarations use the
private modifier where possible, since such declarations apply only to
the immediately declaring class--serialVersionUID fields are not
useful as inherited members. Array classes cannot declare an explicit
serialVersionUID, so they always have the default computed value, but
the requirement for matching serialVersionUID values is waived for
array classes.
There is a similar Thread. Check this here
It is important when you serialize and de-serialize the same class using different VMs or on different machines. The UID is used to check, if the class you are trying to de-serialize is the really the one you think it is, so if your class in your code has one UID, and the class that was serialized has a different one, the de-serialization will fail.
A class without a UID will be given one automatically by the JVM, but there is no guarantee that different JVMs will give the same UID to the same class.
You can also refer this, which I found from SO:
What is a serialVersionUID and why should I use it?
http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does it mean: The serializable class does not declare a static final serialVersionUID field?
Java compiler warning: The serializable class [*****] does not declare a static final serialVersionUID field of type long.
Why? How to fix it?
This is explained fairly well here:
The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.
You fix the error by adding
private static final long serialVersionUID = 7526472295622776147L; // unique id
to the class.
Further reading:
java.io.Serializable
Why should I bother about serialVersionUID? (stackoverflow)
A side note: If you're using Eclipse and if you (and no one else) ever plan to serialize your classes, you can also suppress the error by going to
Window → Preferences → Java → Compiler → Errors/Warnings
and select "Ignore" on "Serializable Class without serialVersionUID".
just add
private static final long serialVersionUID = 1L;//or some long
Docs describe it pretty well
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. It is also
strongly advised that explicit
serialVersionUID declarations use the
private modifier where possible, since
such declarations apply only to the
immediately declaring
class--serialVersionUID fields are not
useful as inherited members.
Also See
why-should-i-bother-about-serialversionuid
Declare it like that:
private static final long serialVersionUID = -4673040337179571462L;
Its required by serializable interface.
Are you extending a Swing object?
I often use the #suppressWarnings annotation to rid myself of this warning.
I guess the question of surpressing the warning or supplying a unique ID depends on the scale of your application and your intended use of Object serialisation.