当前位置:  开发笔记 > 编程语言 > 正文

使用serialVersionUID还是禁止警告?

如何解决《使用serialVersionUID还是禁止警告?》经验,为你挑选了5个好方法。

我想创建一个类,例如,扩展HttpServlet?我的编译器警告我,我的类应该有一个serialVersionUID.如果我知道这个对象永远不会被序列化,我应该定义它还是添加注释来抑制这些警告?

你会做什么以及为什么?



1> Steve Jessop..:

我不了解Java最佳实践,但我发现如果你声称序列化永远不会发生,你可以添加一个抛出的writeObject方法.然后压制警告,安全地知道它不可能适用于你.

否则有人可能会在将来通过父类序列化您的对象,并最终得到一个默认的序列化形式,其中:

表单在不同版本的代码之间不兼容.

你已经压制了这种情况的警告.

添加ID听起来像是一个bodge,因为你真正想做的不是序列化.期望调用者不要序列化你的对象意味着你希望他们在他们的HttpServlet属于你的类时"知道".对于拥有一个不能序列化的Serializable对象而言,多态性的破坏就在您的头上,而您至少可以做的是确保不知情的调用者知道它.


@Justin不可靠不是我希望在与我的应用程序相同的句子中提到的一个词.

2> Benno Richte..:

如果您不打算序列化实例,请添加SuppressWarning.

生成的序列ID可能有点危险.它表明你故意给它一个序列号,并保存为序列化和反序列化.很容易忘记在更新类的应用程序的更新版本中更新序列号.如果类字段已更改,则反序列化将失败.让SuppressWarning至少告诉读者你的代码,你不打算序列化这个类.



3> ykaganovich..:

我拒绝被Eclipse恐吓为我的代码添加杂乱!

我只是将Eclipse配置为在缺少serialVersionUID时不生成警告.


我认为添加@suppressWarning并在不支持序列化时抛出异常是专业环境中的最佳方法.在很多情况下,您的IDE会记住序列化可能很重要.

4> 小智..:

谢谢@ Steve Jessop对此的回答.这是5行代码......几乎没有麻烦.

@SuppressWarnings("serial")刚刚在课堂上方添加了问题.

我还添加了这个方法:

private void writeObject(ObjectOutputStream oos) throws IOException {
   throw new IOException("This class is NOT serializable.");
}

希望这就是史蒂夫的意思:)



5> serg..:

即使您知道该对象将被序列化,也不需要生成serialVersionUID,因为java会自动为您生成它并自动跟踪更改,因此您的序列化将始终正常工作.只有在知道自己在做什么时才应生成它(向后序列化兼容性,手动更改跟踪等)

所以我想说在大多数情况下,抑制警告是最好和最安全的解决方案.


@Scott即使在序列化时也不总是需要提供显式版本值.这取决于序列化范围和未反序列化的后果.如果您只反序列化由相同版本的代码序列化的对象(如在Android上保存实例状态),那么自动生成的ID就可以了.此外,如果您的序列化对象只是一个缓存,如果序列化失败,您可以重建,那也没关系.手动ID会增加很多开发开销,因为您需要在反序列化中正确地处理版本偏差.
如果要序列化某些内容,则应始终提供显式版本值(1,2,3,...).这允许您在兼容性被破坏时告诉Java序列化.例如,如果你所做的只是添加字段,它仍然可以读取具有相同版本的旧.ser文件.
推荐阅读
牛尾巴2010
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有