Question

我的Eclipse在保存Java文件时自动执行许多代码清理操作，其中尽可能将final添加到private字段。

这会与Hibernate将实体属性注入私有字段的能力发生冲突吗？

@Id
private final Long id = null;   // Eclipse made this "final"
                                // but Hibernate needs to set the id

我应该关闭此保存操作吗？

更新：我已经测试了应用程序，并且还使用调试器查看了它，而Hibernate确实重置了“最终”字段，因此事情继续正常工作。但是这可以保证有效吗？例如，是否没有依赖于真正最终字段的VM或编译器优化。那些可能会破裂。另一方面，能够通过反射设置private字段似乎是受支持的场景，所以同样的想法可能也适用于final？

Answer 1

即使有效，也不要这样做。

最后一个字段可以写一次，并且java内存模型的一部分基于这个事实。

我发现这个博客http://www.polygenelubricants.com/2010/03/modifying-static-final-fields-through.html表明可以通过真实的Hack设置最终的反射。（但请不要在任何实际应用中这样做。）

这是对相关问题的回答：Is there any way to declare final fields for Hibernate-managed objects?

在你的情况下，最简单的灵魂就是：让场地变得可变，并且只提供一个吸气剂而不是一个吸气剂。

Answer 2

嗯有趣的问题。我认为对于持久化对象，你可能不想自动设置最终版本，这正是你提到的原因。

如果您的类具有某种类似

的功能，那肯定会有问题

setProperty(int prop) {
    this.prop = prop;
    fireChanged(); // updates other fields that depend on this one
}

我在专业背景下看到过。虽然可能在这里，插件足够聪明，不能让它成为最终版。

如果你想使你的对象不可变，你可以让你的持久类返回一个自己的不可变子类，其中字段是私有的....

因此该插件有优点和缺点。我想你可以这样做，只要你有测试来验证自动生成的决赛不会妨碍。我个人不会使用那个插件 - 我会看看IDE警告并挑选我的决赛......

Hibernate设置的字段可以是最终的吗？

2 个答案: