为什么 const 和 goto 没有在 java 中使用？

更新

Java 规范（§3.9. 关键字）指定了保留的原因const和goto，这与未来的计划无关：

关键字 const 和 goto 是保留的，即使它们当前未被使用。如果这些 C++ 关键字不正确地出现在程序中，这可能允许 Java 编译器生成更好的错误消息。
关键字const和goto是保留的，尽管当前未使用。如果这些 C++ 关键字在程序中被误用，这将允许 Java 编译器生成更清晰的错误消息。

那。Java 开发人员最初并没有计划使用这些词，而是保留它们以在复制用 C++ 编写的代码时捕获错误（如果变量可以命名为goto其中之一const，则复制的 C++ 代码可能会错误地编译并在执行时导致意外结果）。自 JLS 第一版以来，规范的这一部分没有改变。

以下是答案的原始版本，它解决了在 Java中寻找用途const的尝试。goto

Many letters: const并goto从 C++ 搬来。Java 中没有使用关键字。它们在 C++ 中执行的功能在 Java 中的实现方式不同。

故事

从历史上看，Java 的语法是基于 C++ 的，因此开发人员选择保留一些 C++ 关键字来：

• 复制用 C++ 编写的代码时捕获错误；
• 将来在扩展语言时使用它们；
• 简化 C++ 开发人员向 Java 的过渡。

const和goto

所以问题归结为：“Java 是否需要const，goto他们应该做什么？”

常数

const可以在链接中查看其中一项与C ++类推的建议：

JDK-4211070：Java 应该支持用于代码维护的常量参数（如 C++）

该提议于 2005 年结束。通过链接，您可以看到分析，在结论中指出了与输入相关的问题const：

• 现在添加 const 为时已晚。如果这是从 1.0 添加的，情况可能会有所不同。

• Const 污染：C++ 方法要求所有 const 方法都标有 const 关键字。这意味着大多数方法必须显式标记为 const。这往往会使 C++ 中的所有方法变得混乱。

• 兼容性是JDK的一个非常重要的特性。可以说，应该修改集合类以指示元素是常量。这将需要以相同的方式更新所有现有的实现，从而有效地破坏集合接口的所有现有的非 JDK 实现。类似地，
  hashCode 必须是 const，打破了 String 的当前实现。

已经提供了在 Java 中创建 const 变量/字段final。从 C++ 引入机制被认为是不合理的。

去

名声goto不好（参见 Dijkstra 的“ Go To Statement Considered Harmful ”）。Java 有替代的跳转运算符：break, continue, return，涵盖了大部分范围。唯一赞成的论据goto是，在某些情况下，使用goto允许您简化代码。显然，支持者goto无法对开发人员产生足够的影响来添加新关键字。

英文版的类似讨论：

• 为什么 Java 中没有 Constant 特性？
• Java中有goto语句吗？

goto被认为是“糟糕的操作员”，会损害可读性并增加代码混淆，生成难以维护的“意大利面条代码”（也违反了非常重要的编程概念，可以在答案末尾的链接中找到）。

一些认真的人认为它在编程语言中没有立足之地，并写了整本书。因此，当有人在谈论它时，Java 的创建者正在这样做。他们真诚地相信，如果没有无条件的转变，世界会变得更仁慈一点，就所有问题和优势而言，人们可以同意他们的看法。更多的

这个词本身是在创建语言的阶段保留下来的，是从当时其他流行的词中迁移而来的。所以还是在说...

PS：Java还是有通过操作符break和continue标签实现的无条件跳转。您使用它们的频率如何？您是否完全了解这种可能性（这是关于此操作员的需求）？

例如，它们可能不被使用，但在语言中，作为将来的保留，以便在未来的版本中很容易添加这个运算符并且不会与已经编写的代码中的变量/对象的名称相交(Legacy) 在旧版本的语言中。

在 JavaScript 中，似乎也是同样的做法。

关于const哪些可以更换public static final：

JAVA 开发人员没有理由在以后实现 const 并添加所谓的“语法糖”，当您可以这样那样做时，结果程序将以相同的方式运行。

例如，C# 有很多语法糖：

1. 您可以通过别名 (int) 或类型本身 (Int32) 声明变量
2. 有 LINQ，它允许您在简单的情况下不使用循环等...