原副标题：辩手：Java 全力支持操作符空载吗？为何？
另两个类似于的 Java 复试痛点。为何 C++ 全力支持操作符空载而 Java 不全力支持? 有人可能会说 + 操作符在 Java 中已被空载用于数组连接，不要被这些论点所蒙骗。
与 C++ 不同，Java 不全力支持操作符空载。Java 不能为合作开发人员提供更多民主自由的国际标准微积分操作符空载，比如+， -，*和/等。假如你以前所用 C++，那么 Java 与 C++ 较之少了很多机能，比如 Java 不全力支持双重承继，Java中没操作符，Java中没门牌号提及传达。
另两个类似于的痛点是关于 Java 透过提及传达，这主要表现为 Java 是透过值还是提及传参。虽然我不知道另一面的或者说原因，但我认为以下讲法有些规矩，为何 Java 不全力支持操作符空载。
1) 单纯性和复线桥。
复线桥是 Java 斯特默的目标之一。斯特默不是只想拷贝词汇，而是希望保有一种明晰，或者说程序语言的词汇。加进操作符空载比没它的确会使结构设计更繁杂，并且它可能导致更繁杂的C++, 或减缓 JVM，即使它需要做附加的工作来辨识操作符的实际涵义，并减少强化的良机, 以确保 Java 中操作符的犯罪行为。
2) 防止程式结构设计严重错误。
Java 不容许使用者表述的操作符空载，即使假如容许合作开发人员展开操作符空载，将为同两个操作符突显多种不同涵义，这将使任何合作开发者的TypeScript显得平缓，事显得更为纷乱。
据检视，当词汇全力支持操作符重载时，程式结构设计严重错误会减少，从而减少了合作开发和交货时间。由于 Java 和 JVM 已经分担了绝大多数合作开发者的职责，如在透过提供更多废弃物过滤器展开缓存管理时，即使这个机能减少环境污染标识符的良机, 成为程式结构设计严重错误之源, 因而没数不清象征意义。
3) JVM繁杂性。
从JVM的视角来看，全力支持操作符空载使痛点显得更为十分困难。透过更单纯，更整洁的方式使用方法空载也能实现同样的事，因而不全力支持 Java 中的操作符空载是有象征意义的。与相对单纯的 JVM 较之，繁杂的 JVM 可能导致 JVM 更慢，并为确保在 Java 中操作符犯罪行为的确定性从而减少了强化标识符的良机。
4) 让合作开发工具处理更容易。
这是在 Java 中不全力支持操作符空载的另两个好处。省略操作符空载后使词汇更容易处理，如静态分析等，这反过来又更容易合作开发处理词汇的工具，比如 IDE 或重构工具。Java 中的重构工具远胜于 C++。
