一些java类中为什么需要重载 serialVersionUID 属性。
在Java中，软件的兼容性是一个大问题，尤其在使用到对象串行性的时候，那么在某一个对象已经被串行化了，可是这个对象又被修改后重新部署了，那么在这种情况下，用老软件来读取新文件格式虽然不是什么难事，但是有可能丢失一些信息。
serialVersionUID来解决这些问题，新增的 serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。通过这种方式来解决不 同的版本之间的串行话问题。

提纲：
━━━━━━━━
一、概述
二、Java串行化
三、引入版本编号
四、结束语
━━━━━━━━
一、概述
一个程序正式发行出去之后，如果要增加一些新的功能，往往意味着同时要修改用户保 存数据的方式，也就是必须更改程序保存文件的格式——通常是增加保存到文件的数据。有些时候，文件格式必须作彻底的改动，以配合实现程序的新功能。从这个 意义上看，文件格式的发展/变化总是和程序的功能改进相呼应。
但是，大多数情况下，把原有的数据格式一丢了事是行不通的。动物王国中，不能适应环境意味着死亡；软件领域也相似，新软件是否支持原有的数据格式很大程度上决定了用户是否升级。
不管软件新增/改进了多少功能，不管新的文件格式是多么完美，如果新软件不能利用原来的文件格式，用户一般不太会认可新软件。解决该问题的办法包括：
●保留老代码来读取老文件。采用这种方案一般需要额外编写一些代码，把老文件转换 成新的格式（一般地，最简单的办法是先把老文件的数据转换成新的内部对象，然后利用现有的写入新版文件格式的对象）。这种办法的好处是既保留了原有的代 码，又使它与新的文件格式兼容。但是，这种办法有时可能导致丢失部分数据，不过总要比丢失全部数据好。
●使新版软件能够读/写老文件格式。这种办法工作量较大，因为程序的新版本一般会增加一些原来没有的功能，老的数据格式中通常缺乏新功能必需的某些数据。
当新版软件对原来执行任务的方式作了根本性的变动时，丢失数据决非难得一见的偶然 事件。如果新版软件采用和原来不同的方式达到同样的效果，原来的功能可能不再有保留的必要。例如，如果一个程序原来用Swing做用户界面，现在把它改成 了Web（浏览器）用户界面，原来的许多用户界面设置就不再有效。
又如，如果有一个邮件程序，原来用的是以文件夹为基础的索引，现在把它改成了以单词为基础的索引系统，在升级索引文件格式的过程中就有可能丢失许多信息；如果原来的索引文件保存了许多用户配置选项和优化措施，在新的索引系统中这些数据可能无法利用。
这类问题没有绝对完美的解决办法，但是我们可以采取一些措施，使得升级文件格式带 来的负面影响尽可能小。Java串行化（Serialization）有着简单易用的特点，日益成为一种保存文件的重要手段，有鉴于此，下面我们就来看看 在软件版本变更过程中，通过Java串行化保存的文件如何保持兼容性。
二、Java串行化
Java串行化有许多优点：
●容易使用。
●如果一个对象连接到其他对象，串行化机制会保存所有相关的对象。
●如果某个对象出现多次，串行化机制只保存一次。这一点极为重要，它不仅减小了文件空间，而且即使代码写得不是很老练，也不必担心会出现无限循环（一个不老练的例子是，用递归的方式保存各个对象，却又未能有效审计哪些对象已经保存，这时就有可能陷入永无终止的循环）。
遗憾的是，Java串行化机制定义的文件格式似乎很脆弱，只要稍微改动一下类的定义，原来保存的对象就可能无法读取。例如，下面是一个简单的类定义：
public class Save implements Serializable
{
String name;
public void save() throws IOException
{
FileOutputStream f = new FileOutputStream("foo");
ObjectOutputStream oos = new ObjectOutputStream(f);
oos.writeObject(this);
oos.close();
}
}

如果在这个类定义中增加一个域，例如final int val = 7;，再来读取原来保存的对象，就会出现下面的异常：
java.io.InvalidClassException:
Save; local class incompatible:
stream classdesc serialVersionUID = -2805284943658356093,
local class serialVersionUID = 3419534311899376629

上例异常信息中的数字串表示类定义里各种属性的编码值：
●类的名字（Save）。
●域的名字（name）。
●方法的名字（Save）。
●已实现的接口（Serializable）。
改动上述任意一项内容（无论是增加或删除），都会引起编码值变化，从而引起类似的 异常警报。这个数字序列称为“串行化版本统一标识符”（serial version universal identifier），简称UID。解决这个问题的办法是在类里面新增一个域serialVersionUID，强制类仍旧使用原来的UID。新增的域 必须是：
●static：该域定义的属性作用于整个类，而非特定的对象。
●final：保证代码运行期间该域不会被修改。
●long：它是一个64位的数值。
也就是说，新增的serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。
当然，改动之后的类不一定能够和原来的对象兼容。例如，如果把一个域的定义从 String改成了int，执行逆-串行化操作时系统就不知道如何处理该值，显示出错误信 息：java.io.InvalidClassException: Save; incompatible types for field name。
Java串行化规范（http://java.sun.com/j2se/1.4.1/docs/guide/
serialization/spec/serialTOC.doc.html）提供了有关兼容的改动（http://java.sun.com/j2se/1.4.1/docs/
guide/serialization/spec/version.doc7.html）和不兼容改动（http://java.sun.com/j2se/1.4.1/docs/guide/
serialization/spec/version.doc8.html）的清单，这些清单指出了对类作了哪些改动之后仍可能读取原来串行化的数据。具体细节比较复杂，但了解其主要机制还是很容易的：


简而言之，如果文件中确实保存了所有必需的数据，那么仍有可能读取该文件，当然前提是必须处理好串行化的UID。
三、引入版本编号
许多程序都在无意之中作出了这样的假设：这种文件格式是我要用到的最后一种格式， 以后不再需要制定新的格式，现在要做的是处理好在此之前的各种格式。这种程序会试图读取格式版本更高的文件，操作进行到一半才发现某些不能识别的数据，然 后就是突然崩溃。如果文件包含了大量的元数据（描述文件本身的数据），处理起来就要容易得多。
在Java中，每一个域都由其名称显式标明，只要文件的改动不是很大（只添加了域，没有被删除或作重大更改的域），可以想象，用老软件来读取新文件格式不是什么难事，虽然有可能丢失一些信息，但可以搞清楚文件的基本情况。
文件格式随着程序功能的改变而改变。理想情况下，程序应当做到既向后兼容（新的版本能够按照老版本的格式读取，甚至可能允许更新），同时做到向前兼容（较老的软件能够识别和处理新版的文件格式）。
通常，文件的版本无法从表面上一眼看出。大多数程序不会因为文件的版本不同而更改 文件扩展名，而且目前尚无统一的标记文件版本的办法。因此，有关文件格式的版本声明只能在文件本身之内进行。如果你现在使用的文件格式还不包含版本声明， 最好在下次把文件升级成一个不兼容的版本时马上加入版本标记，或者寻求一种在当前文件格式中加入版本标记但不会带来负面影响的办法。
版本信息一般在文件的开头声明，这是因为程序必须在处理文件之前首先检查文件的版本，除非确定了文件的版本，否则不必读取文件的其余部分。

一些java类中为什么需要重载 serialVersionUID 属性。
在Java中，软件的兼容性是一个大问题，尤其在使用到对象串行性的时候，那么在某一个对象已经被串行化了，可是这个对象又被修改后重新部署了，那么在这种情况下，用老软件来读取新文件格式虽然不是什么难事，但是有可能丢失一些信息。
serialVersionUID来解决这些问题，新增的 serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。通过这种方式来解决不 同的版本之间的串行话问题。

提纲：
━━━━━━━━
一、概述
二、Java串行化
三、引入版本编号
四、结束语
━━━━━━━━
一、概述
一个程序正式发行出去之后，如果要增加一些新的功能，往往意味着同时要修改用户保 存数据的方式，也就是必须更改程序保存文件的格式——通常是增加保存到文件的数据。有些时候，文件格式必须作彻底的改动，以配合实现程序的新功能。从这个 意义上看，文件格式的发展/变化总是和程序的功能改进相呼应。
但是，大多数情况下，把原有的数据格式一丢了事是行不通的。动物王国中，不能适应环境意味着死亡；软件领域也相似，新软件是否支持原有的数据格式很大程度上决定了用户是否升级。
不管软件新增/改进了多少功能，不管新的文件格式是多么完美，如果新软件不能利用原来的文件格式，用户一般不太会认可新软件。解决该问题的办法包括：
●保留老代码来读取老文件。采用这种方案一般需要额外编写一些代码，把老文件转换 成新的格式（一般地，最简单的办法是先把老文件的数据转换成新的内部对象，然后利用现有的写入新版文件格式的对象）。这种办法的好处是既保留了原有的代 码，又使它与新的文件格式兼容。但是，这种办法有时可能导致丢失部分数据，不过总要比丢失全部数据好。
●使新版软件能够读/写老文件格式。这种办法工作量较大，因为程序的新版本一般会增加一些原来没有的功能，老的数据格式中通常缺乏新功能必需的某些数据。
当新版软件对原来执行任务的方式作了根本性的变动时，丢失数据决非难得一见的偶然 事件。如果新版软件采用和原来不同的方式达到同样的效果，原来的功能可能不再有保留的必要。例如，如果一个程序原来用Swing做用户界面，现在把它改成 了Web（浏览器）用户界面，原来的许多用户界面设置就不再有效。
又如，如果有一个邮件程序，原来用的是以文件夹为基础的索引，现在把它改成了以单词为基础的索引系统，在升级索引文件格式的过程中就有可能丢失许多信息；如果原来的索引文件保存了许多用户配置选项和优化措施，在新的索引系统中这些数据可能无法利用。
这类问题没有绝对完美的解决办法，但是我们可以采取一些措施，使得升级文件格式带 来的负面影响尽可能小。Java串行化（Serialization）有着简单易用的特点，日益成为一种保存文件的重要手段，有鉴于此，下面我们就来看看 在软件版本变更过程中，通过Java串行化保存的文件如何保持兼容性。
二、Java串行化
Java串行化有许多优点：
●容易使用。
●如果一个对象连接到其他对象，串行化机制会保存所有相关的对象。
●如果某个对象出现多次，串行化机制只保存一次。这一点极为重要，它不仅减小了文件空间，而且即使代码写得不是很老练，也不必担心会出现无限循环（一个不老练的例子是，用递归的方式保存各个对象，却又未能有效审计哪些对象已经保存，这时就有可能陷入永无终止的循环）。
遗憾的是，Java串行化机制定义的文件格式似乎很脆弱，只要稍微改动一下类的定义，原来保存的对象就可能无法读取。例如，下面是一个简单的类定义：
public class Save implements Serializable
{
String name;
public void save() throws IOException
{
FileOutputStream f = new FileOutputStream("foo");
ObjectOutputStream oos = new ObjectOutputStream(f);
oos.writeObject(this);
oos.close();
}
}

如果在这个类定义中增加一个域，例如final int val = 7;，再来读取原来保存的对象，就会出现下面的异常：
java.io.InvalidClassException:
Save; local class incompatible:
stream classdesc serialVersionUID = -2805284943658356093,
local class serialVersionUID = 3419534311899376629

上例异常信息中的数字串表示类定义里各种属性的编码值：
●类的名字（Save）。
●域的名字（name）。
●方法的名字（Save）。
●已实现的接口（Serializable）。
改动上述任意一项内容（无论是增加或删除），都会引起编码值变化，从而引起类似的 异常警报。这个数字序列称为“串行化版本统一标识符”（serial version universal identifier），简称UID。解决这个问题的办法是在类里面新增一个域serialVersionUID，强制类仍旧使用原来的UID。新增的域 必须是：
●static：该域定义的属性作用于整个类，而非特定的对象。
●final：保证代码运行期间该域不会被修改。
●long：它是一个64位的数值。
也就是说，新增的serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。
当然，改动之后的类不一定能够和原来的对象兼容。例如，如果把一个域的定义从 String改成了int，执行逆-串行化操作时系统就不知道如何处理该值，显示出错误信 息：java.io.InvalidClassException: Save; incompatible types for field name。
Java串行化规范（http://java.sun.com/j2se/1.4.1/docs/guide/
serialization/spec/serialTOC.doc.html）提供了有关兼容的改动（http://java.sun.com/j2se/1.4.1/docs/
guide/serialization/spec/version.doc7.html）和不兼容改动（http://java.sun.com/j2se/1.4.1/docs/guide/
serialization/spec/version.doc8.html）的清单，这些清单指出了对类作了哪些改动之后仍可能读取原来串行化的数据。具体细节比较复杂，但了解其主要机制还是很容易的：


简而言之，如果文件中确实保存了所有必需的数据，那么仍有可能读取该文件，当然前提是必须处理好串行化的UID。
三、引入版本编号
许多程序都在无意之中作出了这样的假设：这种文件格式是我要用到的最后一种格式， 以后不再需要制定新的格式，现在要做的是处理好在此之前的各种格式。这种程序会试图读取格式版本更高的文件，操作进行到一半才发现某些不能识别的数据，然 后就是突然崩溃。如果文件包含了大量的元数据（描述文件本身的数据），处理起来就要容易得多。
在Java中，每一个域都由其名称显式标明，只要文件的改动不是很大（只添加了域，没有被删除或作重大更改的域），可以想象，用老软件来读取新文件格式不是什么难事，虽然有可能丢失一些信息，但可以搞清楚文件的基本情况。
文件格式随着程序功能的改变而改变。理想情况下，程序应当做到既向后兼容（新的版本能够按照老版本的格式读取，甚至可能允许更新），同时做到向前兼容（较老的软件能够识别和处理新版的文件格式）。
通常，文件的版本无法从表面上一眼看出。大多数程序不会因为文件的版本不同而更改 文件扩展名，而且目前尚无统一的标记文件版本的办法。因此，有关文件格式的版本声明只能在文件本身之内进行。如果你现在使用的文件格式还不包含版本声明， 最好在下次把文件升级成一个不兼容的版本时马上加入版本标记，或者寻求一种在当前文件格式中加入版本标记但不会带来负面影响的办法。
版本信息一般在文件的开头声明，这是因为程序必须在处理文件之前首先检查文件的版本，除非确定了文件的版本，否则不必读取文件的其余部分。