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

【问题标题】：Is there a technical reason that prevents final in Java from being as strict as const in C++?是否有技术原因阻止 Java 中的 final 与 C++ 中的 const 一样严格？
【发布时间】：2020-02-06 21:41:05
【问题描述】：

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

const SomeClass* p; // 数据不变

或

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

或

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

在 Java 中，final 关键字受到更多限制：

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

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

Java 对象由垃圾收集器管理这一事实是否有影响？

【问题讨论】：

我从未标记过要迁移到 cs.stackexchange.com 的任何内容，但我想知道这个问题是否更适合那里。
@Kayaman：我改了措辞
相关/可能是骗子：stackoverflow.com/questions/2735736/…
我不认为可以用有意义的方式回答这个问题。既然 C++ 有它，就不可能有一个纯粹的技术理由阻止在另一种语言中使用这个特性。显然，这是可能的，但生成的语言将是不同的语言，其他功能可能会受到影响。但这对于每个设计决策都是正确的，因此允许看起来该决策仍算作设计而不是技术决策的语言有何不同？
const 确实影响功能。这会影响重载解析（因此，在 C++ 中，双 getter，iterator 和 const_iterator）。复杂性/安全性的权衡或许可以解释为什么某些语言拥有它而其他语言没有或部分没有。

标签： java c++ constants final

【解决方案1】：

第一个原因是 Java final 与 C++ const 的用途不同。它确实服务的目的很好，这是对面向对象类的层次结构的语义限制，以促进这种层次结构的正确设计。这与无法更改类的值/状态没有任何关系。

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

从那时起，Java 已经发展了很多 - 但在向后兼容性和易于教授语言方面存在严重限制 - 因此语言（以及运行它的 VM 及其框架）的发展非常刻意地进行. （因此，慢慢地。）

并且有一种感觉（有道理），你可以通过声明“const”-ishness 获得很多东西，而使用语言中的其他面向对象的特性，例如，字段有 getter，但没有 setter。

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

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

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

【讨论】：