Java中serialVersionUID----一不小心让我们的交付团队带来了数据修正工作

最近我们的产品在山东港试运行，由于上个月对我们的工作流平台提出了流程预设置需求。在大多数流程平台采用配置到人的策略时，我们全面引入了执行者作为审批人员基础。

在配置过程中，为了让流程在集团内广泛适用，并能自动按照规则完成符合身份人员参与到流程审批中，执行者与参照体系让我们的工作流平台拥有了绝对优先的能力。

但广泛适用的同时，审批人员将无法完全准确获取，会签节点暂时是无法提供自动识别能力的，需要发起人在流程发起时，对整体业务流程中的执行者进行一次设置，及流程预设置功能。

流程预设置是工作流引擎的一个高度中和运用。在这次调整中对组织结构的员工模型添加了属性，由于没有为对象添加serialVersionUID属性，使虚拟机在进行对象序列化时自动生成了个serialVersionUID编号。

生成规则是根据包名，类名，继承关系，非私有的方法和属性，以及参数，返回值等诸多因子计算得出的，极度复杂生成的一个64位的哈希字段。

也就意味着如果模型对象变化，serialVersionUID的值就不一致。虚拟机在序列化反序列化时，会优先对比serialVersinUID，如果不一致，将不进行反序列化。这就意味者对象不兼容了，

昨天的问题由于对象不兼容，时在途流程无法正常支持。由于产品在试运行期，并且刚下通知试用预设置功能。所以在跟换版本后的两个小时内，全集团上报了60多份合同，为了兼容大局，全库中有2k多流程业务单据，为了大局，只能把serivlVersionUID设置到先前版本，这60多份业务单据只能进行手动处理了..........

所以：在今天之后的模型构建中，必须为所有支持序列化的对象提供serialversionUID值，原则上在后续的版本中不允许修改，如果需要修改，需要对序列化与反序列化进行评估后执行。

private static final long  serialVersionUID = xxxxL;