是否有技术原因阻止 Java 中的 final 像 C++ 中的 const 一样严格？

Question

在 C++ 中，可以使用const关键字来指示指向数据的指针或数据本身是常量（或两者），即

const SomeClass* p; // 数据是常量

或者

SomeClass* const p; // 指针是常量

或者

const SomeClass* const p; // 两者都是常数

在 Java 中，final 关键字的限制要大得多：

final SomeClass o; // 引用是常量，对象是可以改变的

我一直想知道为什么 Java 在这方面比 C++ 更有限。这是由语言设计者做出的决定（可能也有其他决定），还是有技术原因阻止它？

Java 对象由垃圾收集器管理这一事实在这里有影响吗？

Answer 1

第一个原因是 Java final 与 C++ const 的用途不同。它的罚款为目的，不发球，这是要在面向对象的类层次结构中的语义限制，推动这种层次结构的合理设计。这与无法更改类的值/状态没有任何关系。

第二个原因是没有什么可以阻止 Java 具有某种“const”特性。但它最初是为一个非常有限的用例设计的（与其当前的各种用例相比有限），它以简单的方式在资源有限的微型设备上进行嵌入式计算。考虑到该用例，主要的初始目标之一是编程代码的简单性、虚拟机编程的简单性、编译器编程的简单性等等。而“const”-ishness 是他们当时不需要的复杂性。

从那时起，Java 已经发展了很多——但是在向后兼容性和语言教学的易用性方面存在严重的限制——因此语言（以及它运行的虚拟机及其框架）的发展非常刻意。（而且，因此，慢慢地。）

并且有一种感觉（合理的），很多你声明“常量” -ishness您可以与其他面向对象的特性，得到得到什么是在语言，例如，具有领域的getter而不是制定者。

所以没有理由在语言/VM/框架中没有“const”-ishness，除非它没有被认为与其他需要解决的事情一样重要，并且语言中有变通方法。

但是人们已经在 J​​ava 中添加了“const”-ishness - 只是语言标准的外部。查找用于创建“不可变对象”的各种库和工具，看看可以做什么。

（并回答您的最后一个问题：它与 GC 无关。）