什么是 serialVersionUID,为什么要使用它?

Eclipse issues warnings when a serialVersionUID is missing.

The serializable class Foo does not declare a static final serialVersionUID field of type long

What is serialVersionUID and why is it important? Please show an example where missing serialVersionUID will cause a problem.

转载于:https://stackoverflow.com/questions/285793/what-is-a-serialversionuid-and-why-should-i-use-it

20个回答

The docs for java.io.Serializable are probably about as good an explanation as you'll get:

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.

csdnceshi70
笑故挽风 Much of this revolves around serialization and why it should probably NOT be used as an over-the-wire protocol or persistently stored and retrieved via deserialization. It effectively creates an implementation of "equals" at the class-level and without any reasonable method across JVMs and countless apps/classes created by any number of developers to make this consistent/unique for a given class... creates a nuanced bug immediately for junior developers should they persist the class as serialized data and then let the compiler try to sort out the version of a class during deserialization.
大约 2 年之前 回复
csdnceshi65
larry*wei Tip: If you've forgotten to add the serialVersionUIDfield, and you wish to change the class without affecting it, you can check what is its value on the unmodified and set it on this class after you've modified it, using this call (found from : stackoverflow.com/a/26822688/878126): long serialVersionUID = ObjectStreamClass.lookup(YourClass.class).getSerialVersionUID();
2 年多之前 回复
csdnceshi78
程序go So you're happy that changing your compiler, even if it wouldn't change any of the details of the fields themselves, could make any stored data unreadable? Or adding a public static method, which really shouldn't change serialization details? Having been bitten by exactly this sort of thing before, it's a very definite "con". Now it could be that if the algorithm had been designed better, it would be okay - but with the way it is designed, it's bad news.
3 年多之前 回复
csdnceshi76
斗士狗 I can't see any cons against letting the runtime use the class "signature". Seems to be the perfect solution to me.
3 年多之前 回复
csdnceshi78
程序go There are pros and cons each way, basically.
3 年多之前 回复
csdnceshi76
斗士狗 So, if I understand it correctly, manually specifying the uid is unsafer than letting the runtime generate it. Because sooner or later someone will forget to update it....
3 年多之前 回复
csdnceshi78
程序go The serialization runtime - it's at execution time.
大约 4 年之前 回复
csdnceshi56
lrony* who generates default UID? JVM or Compiler/JDK?
大约 4 年之前 回复
csdnceshi57
perhaps? Just my two cents this is an issue in Spark and other parallelization APIs that depend on serializing Java classes across a cluster.
接近 5 年之前 回复
weixin_41568131
10.24 Ok, Thanks a lot. Here your answers are great source of knowledge.
接近 5 年之前 回复
csdnceshi78
程序go I don't know exactly what happens in those cases, but why not just declare it separately in each class, as the documentation implies?
接近 5 年之前 回复
weixin_41568131
10.24 If I make it protected then what? Won't it inherited in child class?
接近 5 年之前 回复
csdnceshi78
程序go Yes, you should do so.
接近 5 年之前 回复
weixin_41568131
10.24 You have mentioned in your answer "since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members." could you please explain this? Because as I know if the parent class is serialized the child is also serialized by default, so do we need to declare SerialVersionUID for child as well?
接近 5 年之前 回复
csdnceshi54
hurriedly% If " .. 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." doesn't answer Why then I am afraid, I will have to ask you to define Why :D
大约 5 年之前 回复
csdnceshi68
local-host I think the right word there is ought.
5 年多之前 回复
csdnceshi78
程序go To deserialize data? Yes. It would be odd to deserialize data for a class you didn't have the source to though. Binary serialization shouldn't (IMO) be used as a general purpose public protocol.
接近 6 年之前 回复
csdnceshi59
ℙℕℤℝ So does it mean that besides having an identical class definition, I have to use exactly the same version number? How could I know that if I don't have a peek of the source code of the serialized class?
接近 6 年之前 回复
weixin_41568127
?yb? to answer the why part of you question: Exception implements Serializable and eclipse warns that you have not set an serialVersionUID, which would be a good idea (if you wan't to serialize the class) to avoid the problems that JonSkeet's post outlines.
接近 6 年之前 回复
csdnceshi78
程序go Well I wouldn't expect it to say you need one - but it may be suggesting one in order to help you serialize exceptions correctly. If you're not going to serialize them, you really don't need the constant.
6 年多之前 回复
csdnceshi63
elliott.david And why does Eclipse say I need "private static final long serialVersionUID = 1L;" when I extend the Exception class?
6 年多之前 回复
csdnceshi78
程序go The why is in the second paragraph: if you don't explicitly specify serialVersionUID, a value is generated automatically - but that's brittle because it's compiler implementation dependent.
11 年多之前 回复
csdnceshi73
喵-见缝插针 So, what you are saying essentially is that if a user did not understand all the above material, said user aught not bother worrying about serialization? I believe you answered the "how?" rather than explaining the "why?". I, for one, do not understand why I aught bother with SerializableVersionUID.
11 年多之前 回复

I can't pass up this opportunity to plug Josh Bloch's book Effective Java (2nd Edition). Chapter 11 is an indispensible resource on Java serialization.

Per Josh, 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.)

weixin_41568131
10.24 It is worth noting that Joshua Bloch advices that for every Serializable class it's worth specifying the serial version uid. Quote from chapter 11: Regardless of what serialized form you choose, declare an explicit serial version UID in every serializable class you write. This eliminates the serial version UID as a potential source of incompatibility (Item 74). There is also a small performance benefit. If no serial version UID is provided, an expensive computation is required to generate one at runtime.
大约 6 年之前 回复
csdnceshi76
斗士狗 class Name, implemented interfaces, all public and protected methods,ALL instance variables.
7 年多之前 回复
csdnceshi71
Memor.の Yup, in case if the newer version changes any public member to protected, the default SerializableVersionUID will be different and will raise an InvalidClassExceptions.
8 年多之前 回复
csdnceshi58
Didn"t forge So one might bother with SerializableVersionUID if one were concerned about compatibility w/ old versions of a class?
11 年多之前 回复

You can tell Eclipse to ignore these serialVersionUID warnings:

Window > Preferences > Java > Compiler > Errors / Warnings > Potential Programming Problems

In case you didn't know, there are a lot of other warnings you can enable in this section (or even have some reported as errors), many are very useful:

  • Potential Programming Problems: Possible accidental boolean assignment
  • Potential Programming Problems: Null pointer access
  • Unnecessary code: Local variable is never read
  • Unnecessary code: Redundant null check
  • Unnecessary code: Unnecessary cast or 'instanceof'

and many more.

csdnceshi53
Lotus@ The questioner obviously cares about why there should be an UID. So simply telling him to ignore the warn should be downvoted.
3 年多之前 回复
csdnceshi64
游.程 -> agreed! But the questioner also wants to know why he might not want to be warned.
11 年多之前 回复
csdnceshi78
程序go True - I was assuming the questioner simply didn't want to be warned
接近 12 年之前 回复
csdnceshi77
狐狸.fox upvote but only because the original poster doesn't appear to be serializing anything. If the poster said "i'm serializing this thing and ..." then you'd get a vote down instead :P
接近 12 年之前 回复

If you're serializing just because you have to serialize for the implementation's sake (who cares if you serialize for an HTTPSession, for instance...if it's stored or not, you probably don't care about de-serializing a form object), then you can ignore this.

If you're actually using serialization, it only matters if you plan on storing and retrieving objects using serialization directly. The serialVersionUID represents your class version, and you should increment it if the current version of your class is not backwards compatible with its previous version.

Most of the time, you will probably not use serialization directly. If this is the case, generate a default serializable uid by clicking the quick fix option and don't worry about it.

csdnceshi55
~Onlooker No warning are shown in IDEA by default.
2 年多之前 回复
weixin_41568183
零零乙 If you're not using serialization (in like 99.9999% of the cases) just turn off this stupid default warning. No pointless meaningless random numbers in your code and no unnecessary SuppressWarnings. Jeez, every time I see code bases which "workaround" this warning I really wonder why they not simply turn off this warning (and perhaps activate a few that are more useful), instead of this zombie mentality to just "fix" the warning.
2 年多之前 回复
csdnceshi69
YaoRaoLov Declared serialVersionUID explicitly.
接近 3 年之前 回复
csdnceshi57
perhaps? You mean 'declared' what 'explicitly'?
接近 3 年之前 回复
csdnceshi69
YaoRaoLov I mean declared explicitly
5 年多之前 回复
csdnceshi57
perhaps? What does 'has introduced explicitly' mean?
5 年多之前 回复
csdnceshi69
YaoRaoLov increment of serialVersionUID comes into picture when initial author of the class has introduced explicitly.I would say, jvm generated serial id, should be fine. this is the best answer that i saw on serialisation.
5 年多之前 回复
csdnceshi57
perhaps? "You should increment it if the current version of your class is not backwards compatible with its previous version:" You should first explore the extensive object versioning support of Serialization, (a) to ensure that the class really is now serialization-incompatible way, which per the specification is quite difficult to achieve; (b) to try a scheme such as custom read/writeObject() methods, readResolve/writeReplace() methods, serializableFields declarations, etc, to make sure that the stream remains compatible. Changing the actual serialVersionUID is a last resort, a counsel of despair.
接近 8 年之前 回复
weixin_41568134
MAO-EYE documents the intent better if you don't wish to use the class for permanent storage.
8 年多之前 回复
csdnceshi54
hurriedly% I don't see how adding one line (@SuppressWarnings annotation) as opposed to another line (serializable id) "clutters the class less". And if you're not using serialization for permanent storage, why wouldn't you just use "1"? You would not care about the autogenerated ID in that case anyways.
9 年多之前 回复
csdnceshi76
斗士狗 I'd say that if you're not using serialization for permanent storage, you should use @SuppressWarnings rather than adding a value. It clutters the class less, and it preserves the abiity of the serialVersionUID mechanism to protect you from incompatible changes.
9 年多之前 回复

serialVersionUID facilitates versioning of serialized data. Its value is stored with the data when serializing. When de-serializing, the same version is checked to see how the serialized data matches the current code.

If you want to version your data, you normally start with a serialVersionUID of 0, and bump it with every structural change to your class which alters the serialized data (adding or removing non-transient fields).

The built-in de-serialization mechanism (in.defaultReadObject()) will refuse to de-serialize from old versions of the data. But if you want to you can define your own readObject()-function which can read back old data. This custom code can then check the serialVersionUID in order to know which version the data is in and decide how to de-serialize it. This versioning technique is useful if you store serialized data which survives several versions of your code.

But storing serialized data for such a long time span is not very common. It is far more common to use the serialization mechanism to temporarily write data to for instance a cache or send it over the network to another program with the same version of the relevant parts of the codebase.

In this case you are not interested in maintaining backwards compatibility. You are only concerned with making sure that the code bases which are communicating indeed have the same versions of relevant classes. In order to facilitate such a check, you must maintain the serialVersionUID just like before and not forget to update it when making changes to your classes.

If you do forget to update the field, you might end up with two different versions of a class with different structure but with the same serialVersionUID. If this happens, the default mechanism (in.defaultReadObject()) will not detect any difference, and try to de-serialize incompatible data. Now you might end up with a cryptic runtime error or silent failure (null fields). These types of errors might be hard to find.

So to help this usecase, the Java platform offers you a choice of not setting the serialVersionUID manually. Instead, a hash of the class structure will be generated at compile-time and used as id. This mechanism will make sure that you never have different class structures with the same id, and so you will not get these hard-to-trace runtime serialization failures mentioned above.

But there is a backside to the auto-generated id strategy. Namely that the generated ids for the same class might differ between compilers (as mentioned by Jon Skeet above). So if you communicate serialized data between code compiled with different compilers, it is recommended to maintain the ids manually anyway.

And if you are backwards-compatible with your data like in the first use case mentioned, you also probably want to maintain the id yourself. This in order to get readable ids and have greater control over when and how they change.

csdnceshi71
Memor.の My point remains exactly what I said. Adding or removing non-transient fields doesn't make the class Serialization-incompatible. You therefore don't need to bump the serialVersionUID every time you do so.
5 年多之前 回复
csdnceshi77
狐狸.fox I realize that adding a non-transient field doesn't necessarily mean that you make the class serialization-incompatible, but it is a structural change which alters the serialized data and you usually want to bump the version when doing so unless you handle backwards compatibility, which I also explained later in the post. What is your point exactly?
6 年多之前 回复
csdnceshi71
Memor.の Read what I wrote. I didn't say it doesn't 'change the serialization data'. I said it 'doesn't make the class serialization-incompatible'. It isn't the same thing. You need to read the Versioning chapter of the Object Serialization Specification.
6 年多之前 回复
csdnceshi77
狐狸.fox Huh? Adding data definitely changes the serialization data in my world.
6 年多之前 回复
csdnceshi71
Memor.の Adding or removing non-transient fields doesn't make the class serialization-incompatible. There is therefore no reason to 'bump it' on such changes.
6 年多之前 回复

What is a serialVersionUID and why should I use it?

SerialVersionUID is a unique identifier for each class, JVM uses it to compare the versions of the class ensuring that the same class was used during Serialization is loaded during Deserialization.

Specifying one gives more control, though JVM does generate one if you don't specify. The value generated can differ between different compilers. Furthermore, sometimes you just want for some reason to forbid deserialization of old serialized objects [backward incompatibility], and in this case you just have to change the serialVersionUID.

The javadocs for Serializable say:

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, you must declare serialVersionUID because it give us more control.

This article has some good points on the topic.

weixin_41568183
零零乙 serialVersionUID is not a 'unique identifier for each class'. The fully-qualified class name is that. It is a version indicator.
5 年多之前 回复
csdnceshi79
python小菜 The one thing not mentioned in this answer is that you may cause unintended consequences by blindly including serialVersionUID without knowing why. Tom Anderson's comment on MetroidFan2002's answer addresses this: "I'd say that if you're not using serialization for permanent storage, you should use @SuppressWarnings rather than adding a value. It clutters the class less, and it preserves the ability of the serialVersionUID mechanism to protect you from incompatible changes."
6 年多之前 回复
weixin_41568131
10.24 but serialVersionUID is static so static variables cannot be serialized. then how come jvm will check version, without knowing what is the version of the deserializing object
6 年多之前 回复

If you get this warning on a class you don't ever think about serializing, and that you didn't declare yourself implements Serializable, it is often because you inherited from a superclass, which implements Serializable. Often then it would be better to delegate to such a object instead of using inheritance.

So, instead of

public class MyExample extends ArrayList<String> {

    public MyExample() {
        super();
    }
    ...
}

do

public class MyExample {
    private List<String> myList;

    public MyExample() {
         this.myList = new ArrayList<String>();
    }
    ...
}

and in the relevant methods call myList.foo() instead of this.foo() (or super.foo()). (This does not fit in all cases, but still quite often.)

I often see people extending JFrame or such, when they really only need to delegate to this. (This also helps for auto-completing in a IDE, since JFrame has hundreds of methods, which you don't need when you want to call your custom ones on your class.)

One case where the warning (or the serialVersionUID) is unavoidable is when you extend from AbstractAction, normally in a anonymous class, only adding the actionPerformed-method. I think there shouldn't be a warning in this case (since you normally can't reliable serialize and deserialize such anonymous classes anyway accross different versions of your class), but I'm not sure how the compiler could recognize this.

csdnceshi67
bug^君 Well, that wouldn't be any different if you had numerous ArrayList instances either. An instance of your wrapper class is a size on the order of bytes + the size of the arraylist, whereas through inheritence you would be initializing the same amount but under 1 class definition. References are light, the underlying objects are heavy.
3 年多之前 回复
csdnceshi53
Lotus@ I think this is by design – even if you don't want to serialize your exception class, someone else might want to serialize an exception thrown by you. (Of course, one could argue that most exception classes should be fine with the auto-generated serialVersionUID and not need a fixed one.)
3 年多之前 回复
csdnceshi66
必承其重 | 欲带皇冠 Throwable is serializable, and only Throwable is throwable, so it's not possible to define an exception that isn't serializable. Delegation isn't possible.
3 年多之前 回复
csdnceshi69
YaoRaoLov What I don't like about delegation is the need to hold a reference to the delegate. And every reference means more memory. Correct me if I'm wrong. If I need a CustomizedArrayList of 100 objects then this wouldn't matter much but if I need hundreds of CustomizdeArrayLists of a few objects then memory usage increases significantly.
接近 6 年之前 回复
csdnceshi53
Lotus@ When you would delegate lots of methods to your wrapped object, of course it would not be appropriate to use delegation. But I suppose that this case is a sign of a design mistake - the users of your class (e.g. "MainGui") shouldn't need to call lots of methods of the wrapped object (e.g. JFrame).
大约 8 年之前 回复
csdnceshi68
local-host Surely if you add a class as a member, rather than inheriting from it, you would have to write a wrapper method for EVERY method of the member class that you wished to use, which would make it unfeasible in a large number of situations... unless java has a function similar to perl's __AUTOLOAD, which I don't know about.
大约 8 年之前 回复
csdnceshi74
7*4 I think you're right that composition over inhneritance makes more sense, particularly when you're discussing classes such as ArrayList. However, many frameworks require people to extend from abstract superclasses which are serializable (such as Struts 1.2's ActionForm class, or Saxon's ExtensionFunctionDefinition) in which case this solution is infeasible. I think you're right, it would be nice if the warning were ignored in certain cases (like if you were extending from an abstract serializable class)
接近 9 年之前 回复

To understand the significance of field serialVersionUID, one should understand how Serialization/Deserialization works.

When a Serializable class object is serialized Java Runtime associates a serial version no.(called as serialVersionUID) with this serialized object. At the time when you deserialize this serialized object Java Runtime matches the serialVersionUID of serialized object with the serialVersionUID of the class. If both are equal then only it proceeds with the further process of deserialization else throws InvalidClassException.

So we conclude that to make Serialization/Deserialization process successful the serialVersionUID of serialized object must be equivalent to the serialVersionUID of the class. In case if programmer specifies the serialVersionUID value explicitly in the program then the same value will be associated with the serialized object and the class, irrespective of the serialization and deserialzation platform(for ex. serialization might be done on platform like windows by using sun or MS JVM and Deserialization might be on different platform Linux using Zing JVM).

But in case if serialVersionUID is not specified by programmer then while doing Serialization\DeSerialization of any object, Java runtime uses its own algorithm to calculate it. This serialVersionUID calculation algorithm varies from one JRE to another. It is also possible that the environment where the object is serialized is using one JRE (ex: SUN JVM) and the environment where deserialzation happens is using Linux Jvm(zing). In such cases serialVersionUID associated with serialized object will be different than the serialVersionUID of class calculated at deserialzation environment. In turn deserialization will not be successful. So to avoid such situations/issues programmer must always specify serialVersionUID of Serializable class.

csdnceshi60
℡Wang Yan The algorithm doesn't vary, but it is slightly under-specified.
6 年多之前 回复

First I need to explain the serialization.
Serialization allows to convert the object to stream,for sending that object over the network OR Save to file OR save into DB for letter usage.

There are some rules for serialization.

  • An object is serializable only if its class or its superclass implements the Serializable interface

  • An object is serializable (itself implements the Serializable interface) even if its superclass is not. However, the first superclass in the hierarchy of the serializable class, that does not implements Serializable interface, MUST have a no-arg constructor. If this is violated, readObject() will produce a java.io.InvalidClassException in runtime

  • All primitive types are serializable.

  • Transient fields (with transient modifier) are NOT serialized, (i.e., not saved or restored). A class that implements Serializable must mark transient fields of classes that do not support serialization (e.g., a file stream).

  • Static fields (with static modifier) are Not serialized.

When Object is Serialized JAVA Runtime Associates the serial version number that is called the serialVersionID.

Where we need serialVersionID : During the deserialization to verify that sender and receiver are compatible with respect to serialization.If receiver loaded the class with different serialVersionID then deserialization will end with InvalidClassCastException.
A serializable class can declare its own serialVersionUID explicitly by declaring a field named “serialVersionUID” that must be static, final, and of type long:.

Let's try this with an example.

import java.io.Serializable;    
public class Employee implements Serializable {
private static final long serialVersionUID = 1L;
private String empname;
private byte empage;

public String getEmpName() {
    return name;
}
public void setEmpName(String empname) {
    this.empname = empname;
}
public byte getEmpAge() {
    return empage;
}
public void setEmpAge(byte empage) {
    this.empage = empage;
}

public String whoIsThis() {
    StringBuffer employee = new StringBuffer();
    employee.append(getEmpName()).append(" is ).append(getEmpAge()).append("
years old  "));
    return employee.toString();
}
}

Create Serialize Object

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
public class Writer {
public static void main(String[] args) throws IOException {
    Employee employee = new Employee();
    employee.setEmpName("Jagdish");
    employee.setEmpAge((byte) 30);

    FileOutputStream fout = new 
FileOutputStream("/users/Jagdish.vala/employee.obj");
    ObjectOutputStream oos = new ObjectOutputStream(fout);
    oos.writeObject(employee);
    oos.close();
    System.out.println("Process complete");
}
}

Deserializ the object

import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
public class Reader {
public static void main(String[] args) throws ClassNotFoundException, 
IOException {
    Employee employee = new Employee();
    FileInputStream fin = new 
    FileInputStream("/users/Jagdish.vala/employee.obj");
    ObjectInputStream ois = new ObjectInputStream(fin);
    employee = (Employee) ois.readObject();
    ois.close();
    System.out.println(employee.whoIsThis());
 }
}    

NOTE: Now change the serialVersionUID of the Employee class and save:

private static final long serialVersionUID = **4L**;

And execute the Reader class. Not to execute the Writer class and you will get the exception.

Exception in thread "main" java.io.InvalidClassException: 
com.jagdish.vala.java.serialVersion.Employee; local class incompatible: 
stream classdesc serialVersionUID = 1, local class serialVersionUID = 4
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1623)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at com.krishantha.sample.java.serialVersion.Reader.main(Reader.java:14)

If you will never need to serialize your objects to byte array and send/store them, then you don't need to worry about it. If you do, then you must consider your serialVersionUID since the deserializer of the object will match it to the version of object its classloader has. Read more about it in the Java Language Specification.

csdnceshi64
游.程 Here is the link to the Java 8 Object Versioning Specification.
接近 6 年之前 回复
csdnceshi52
妄徒之命 It isn't mentioned anywhere in the Java Language Specification. It's mentioned in the Object Versioning Specification.
6 年多之前 回复
csdnceshi61
derek5. - the parent class may be serializable, say, ArrayList, but you want your own object (say, a modified array list) to use it as a base but are never going to serialize the Collection that you create.
11 年多之前 回复
csdnceshi73
喵-见缝插针 If you're not going to serialize the objects, why are they Serializable?
接近 12 年之前 回复
共20条数据 1 尾页
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问