在序列化上花了一些时间后，我发现，我们不应该用一些随机值生成serialVersionUID，我们应该给它一个有意义的值。

这里有一个详细的评论。我正在处理这里的评论。

Actually, you should not be "generating" serial version UIDs. It is a dumb "feature" that stems from the general misunderstanding of how that ID is used by Java. You should be giving these IDs meaningful, readable values, e.g. starting with 1L, and incrementing them each time you think the new version of the class should render all previous versions (that might be previously serialized) obsolete. All utilities that generate such IDs basically do what the JVM does when the ID is not defined: they generate the value based on the content of the class file, hence coming up with unreadable meaningless long integers. If you want each and every version of your class to be distinct (in the eyes of the JVM) then you should not even specify the serialVersionUID value isnce the JVM will produce one on the fly, and the value of each version of your class will be unique. The purpose of defining that value explicitly is to tell the serialization mechanism to treat different versions of the class that have the same SVUID as if they are the same, e.g. not to reject the older serialized versions. So, if you define the ID and never change it (and I assume that's what you do since you rely on the auto-generation, and you probably never re-generate your IDs) you are ensuring that all - even absolutely different - versions of your class will be considered the same by the serialization mechanism. Is that what you want? If not, and if you indeed want to have control over how your objects are recognized, you should be using simple values that you yourself can understand and easily update when you decide that the class has changed significantly. Having a 23-digit value does not help at all.

希望这能有所帮助。祝你好运。

如果您想为一堆文件添加缺少的serialVersionUID, IntelliJ IDEA可能不能很好地工作。我想出了一些简单的脚本来轻松实现这个目标:

base_dir=$(pwd)
src_dir=$base_dir/src/main/java
ic_api_cp=$base_dir/target/classes

while read f
do
    clazz=${f//\//.}
    clazz=${clazz/%.java/}
    seruidstr=$(serialver -classpath $ic_api_cp $clazz | cut -d ':' -f 2 | sed -e 's/^\s\+//')
    perl -ni.bak -e "print $_; printf qq{%s\n}, q{    private $seruidstr} if /public class/" $src_dir/$f
done

将这个脚本保存在~/bin文件夹中的add_serialVersionUID.sh。然后在Maven或Gradle项目的根目录下运行:

add_serialVersionUID.sh < myJavaToAmend.lst

这个.lst包含了添加serialVersionUID的Java文件列表，格式如下:

com/abc/ic/api/model/domain/item/BizOrderTransDO.java
com/abc/ic/api/model/domain/item/CardPassFeature.java
com/abc/ic/api/model/domain/item/CategoryFeature.java
com/abc/ic/api/model/domain/item/GoodsFeature.java
com/abc/ic/api/model/domain/item/ItemFeature.java
com/abc/ic/api/model/domain/item/ItemPicUrls.java
com/abc/ic/api/model/domain/item/ItemSkuDO.java
com/abc/ic/api/model/domain/serve/ServeCategoryFeature.java
com/abc/ic/api/model/domain/serve/ServeFeature.java
com/abc/ic/api/model/param/depot/DepotItemDTO.java
com/abc/ic/api/model/param/depot/DepotItemQueryDTO.java
com/abc/ic/api/model/param/depot/InDepotDTO.java
com/abc/ic/api/model/param/depot/OutDepotDTO.java

该脚本使用JDK的serialVer工具。当您希望修改大量最初没有设置serialVersionUID的类，同时保持与旧类的兼容性时，它是理想的。

为了产生价值而使用

private static final long serialVersionUID = $randomLong$L;
$END$

并为randomLong模板变量提供如下值: .nextLong groovyScript(“新随机()().abs ())

https://pharsfalvi.wordpress.com/2015/03/18/adding-serialversionuid-in-idea/

此外，您可以添加活的模板，将做的工作。

按Ctrl+Alt+S -> "Live Templates" section -> other(或w/e你希望)

然后用这样的定义创建一个新的:

private static final long serialVersionUID = 1L;
$END$

然后选择定义范围并将其保存为" serial "

现在您可以在类主体中键入serialTAB。

在另一组中添加一个名为“ser”的活动模板，设置为“applied in Java: declaration”，并取消勾选“Shorten FQ names”。给它一个模板文本:

$serial$

现在编辑变量并设置serial为:

groovyScript("(System.env.JDK_HOME+'/bin/serialver -classpath '+com.intellij.openapi.fileEditor.FileDocumentManager.instance.getFile(_editor.document).path.replaceAll('/java/.*','').replaceAll('/src/','/build/classes/')+' '+_1).execute().text.replaceAll('.*: *','')",qualifiedClassName())

它采用标准的Gradle项目布局。为Maven更改/build/到/target/。

在序列化上花了一些时间后，我发现，我们不应该用一些随机值生成serialVersionUID，我们应该给它一个有意义的值。

这里有一个详细的评论。我正在处理这里的评论。

Actually, you should not be "generating" serial version UIDs. It is a dumb "feature" that stems from the general misunderstanding of how that ID is used by Java. You should be giving these IDs meaningful, readable values, e.g. starting with 1L, and incrementing them each time you think the new version of the class should render all previous versions (that might be previously serialized) obsolete. All utilities that generate such IDs basically do what the JVM does when the ID is not defined: they generate the value based on the content of the class file, hence coming up with unreadable meaningless long integers. If you want each and every version of your class to be distinct (in the eyes of the JVM) then you should not even specify the serialVersionUID value isnce the JVM will produce one on the fly, and the value of each version of your class will be unique. The purpose of defining that value explicitly is to tell the serialization mechanism to treat different versions of the class that have the same SVUID as if they are the same, e.g. not to reject the older serialized versions. So, if you define the ID and never change it (and I assume that's what you do since you rely on the auto-generation, and you probably never re-generate your IDs) you are ensuring that all - even absolutely different - versions of your class will be considered the same by the serialization mechanism. Is that what you want? If not, and if you indeed want to have control over how your objects are recognized, you should be using simple values that you yourself can understand and easily update when you decide that the class has changed significantly. Having a 23-digit value does not help at all.

希望这能有所帮助。祝你好运。