|
|
1
122
序列化充满了陷阱。此表单的自动序列化支持使类内部成为公共API的一部分(这就是javadoc为您提供 persisted forms of classes 对于长期持久性,类必须能够解码此表单,这将限制您对类设计所做的更改。这破坏了封装。 序列化还可能导致安全问题。通过能够序列化它所引用的任何对象,类可以访问它通常无法访问的数据(通过解析结果字节数据)。 还有其他问题,例如内部类的序列化形式没有得到很好的定义。 使所有类都可序列化会加剧这些问题。退房 Effective Java Second Edition 项目74:明智地实现可序列化 |
|
|
2
32
例如,在Smalltalk(70年代创建的一种语言)中,默认情况下每个对象都是可序列化的。考虑到绝大多数对象都可以安全地序列化,而只有少数对象不能,我不知道为什么Java中不是这样。 将对象标记为可序列化(使用接口)并不能神奇地使该对象可序列化, 它一直是可序列化的 ,只是现在你表达了一些系统可以自己发现的东西,所以我认为没有真正好的理由让序列化成为现在的样子。
|
|
|
3
21
|
|
|
4
13
Java中Serializable的主要作用是在默认情况下使所有其他对象都不可序列化。序列化是一种非常危险的机制,尤其是在其默认实现中。因此,就像C++中的友谊一样,默认情况下它是关闭的,即使它使事情变得可串行化也会花费一些。 序列化增加了约束和潜在问题,因为结构兼容性没有得到保证。默认情况下它处于关闭状态是好的。 我必须承认,我见过很少有非平凡的类,在这些类中,标准序列化实现了我想要的功能。特别是在复杂数据结构的情况下。因此,使类可以正确序列化所花费的努力使添加接口的成本相形见绌。 |
|
|
5
9
对于某些类,尤其是那些表示更物理的对象(如文件、套接字、线程或DB连接)的类,序列化实例是毫无意义的。对于许多其他人来说,序列化可能会有问题,因为它会破坏唯一性约束,或者只是迫使您处理一个类的不同版本的实例,而您可能不想这样做。 可以说,在默认情况下使所有内容都可序列化,并通过关键字或标记接口使类不可序列化可能更好,但是,那些应该使用该选项的人可能不会想到这一点。按照这种方式,如果您需要实现Serializable,那么会有一个异常告诉您。 |
|
|
6
4
|
|
|
7
3
显然,在一些初步设计中,所有内容都是可序列化的,但由于安全性和正确性方面的考虑,最终的设计以众所周知的方式结束。 Why must classes implement Serializable in order to be written to an ObjectOutputStream? . |
|
|
8
1
仅仅依靠JVM的标准序列化支持,您就会面临各种令人讨厌的版本控制问题。
|
|
|
9
1
阅读本文了解Serializable接口,以及为什么我们应该只让少数几个类可序列化,并且我们应该注意在何处使用transient关键字,以防我们想从存储过程中删除几个字段。 |
|
|
10
0
嗯,我的回答是,这没有什么好的理由。从你的评论中我可以看出你已经学会了这一点。其他语言乐于尝试序列化在数到10后不会跳到树上的所有内容。对象应默认为可序列化。
|
|
|
11
0
Java中有一些东西根本无法实现 无法序列化,因为它们是特定于运行时的。比如流、线程、运行时、, |
|
|
12
0
虽然我同意这里其他答案中的观点,但真正的问题在于反序列化:如果类定义发生变化,那么反序列化就存在无法工作的真正风险。永远不修改现有字段是库作者的一项重大承诺!维护API兼容性已经足够麻烦了。 |
|
|
13
0
需要持久化到文件或其他媒体的类必须实现可序列化接口,以便JVM可以允许对类对象进行序列化。 对象输出流
如果 serialVersionUID 如果没有提供,那么我们在反序列化对象时会得到意外的结果,这就是JVM抛出 InvalidClassException serialVersionUID 不匹配。因此,每个类都必须实现 可序列化 接口和提供 确保两端呈现的类是相同的。 |
|
|
user29759326 · 如何返回递归函数中的最后一个值? 1 年前 |
|
|
malife89 · 将java中的字符串读取为正确的日期格式 1 年前 |
|
|
Tim · 在java中,有没有更快的方法将字节数组写入文件? 1 年前 |
|
|
rudraraj · java中未声明最终变量 1 年前 |
|
|
Bala Ji · 以下BFS的实施效率如何? 1 年前 |