在研究标准 Java 库及其类时，我不禁注意到其中一些类的方法在我看来与这些类的原因几乎无关。
例如，我正在谈论的方法是Integer#getInteger，它检索某个“系统属性”的值，或者System#arraycopy，其目的由其名称明确定义。尽管如此，这两种方法似乎都有些格格不入，尤其是第一种，它出于某种原因将使用系统资源绑定到原始类型包装类。
从我目前的观点来看，这种方法放置策略似乎违反了基本的 OOP 设计原则：每个类都必须致力于解决其特定的问题集，而不是把自己变成瑞士军刀。但是因为我不认为 Java 设计者是白痴，所以我认为将这些方法放置在它们所在的位置的决定背后有一些逻辑。所以如果有人能解释这个逻辑到底是什么，我将不胜感激。
谢谢！
更新
一些人暗示，Java 确实有一些不合逻辑的东西，它们只是动荡过去的残余。然后我重新提出我的问题：为什么 Java 如此不愿意将其架构缺陷标记为已弃用，因为现有的已弃用功能在任何可观察到的未来都不太可能停止使用，而弃用某些东西确实有助于避免在新的应用中使用它们创建代码？
这是一件值得怀疑的好事情。我知道最近的功能（例如泛型、lambda 等），邮件列表上有几个博客和帖子解释了库制造商所做的选择。这些读起来很有趣。
在你的情况下，我希望答案不会太令人兴奋。制作它们的原因很难说。但是这两个类从 JDK1.0 开始就存在了。在那些日子里，一般的编程质量（尤其是 Java 和 OO）可能较低（这意味着常见的实践更少，图书馆制造商不得不自己发明许多范式）。那个时候还有其他的限制，比如Object创作成本很高。
许多设计笨拙的方法和类现在有了更好的选择。（参见Date和包java.time）arraycopy你希望被添加到Arrays类中，但不幸的是它不存在。
理想情况下，原始方法将被弃用一段时间，然后被删除。许多图书馆都遵循这种策略。然而，Java 对此非常保守，只弃用真正不应该使用的东西（Thread.stop()例如较新版本的 Java，但其代价是在库中留下一些混乱。
java 在保持新的 JDK/JRE 版本与旧的源代码和二进制文件兼容方面如此保守，这一事实令人爱不释手。对于您的爱好项目，或者是一个积极开发的小型项目，升级到新的 JVM 并在几年后删除已弃用的功能并不太难。但是不要忘记许多项目没有积极开发，或者开发人员很难安全地进行更改，例如因为他们缺乏适当的回归测试。在这些项目中，API 的更改需要花费大量时间来遵守，并冒着引入错误的风险。
此外，库通常会尝试支持较旧版本的 Java 以及较新版本，当方法被删除时，它们会遇到问题。
整数示例可能只是一个设计决策。如果您想将属性隐式解释为 Integer，请使用 java.lang.Integer。否则，您必须为每个 java.lang-Type 提供一个 getter 方法。就像是：
对于每种数据类型，您需要一种额外的默认方法： - System.getPropertyAsBoolean(String, boolean) - System.getPropertyAsByte(String, byte) ...
由于 java.lang-Types 已经具有一些强制转换能力（Integer.valueOf(String)），所以在这里找到 getProperty 方法我并不感到惊讶。打破原则的贸易便利。
对于 System.arraycopy，我想这是一个取决于操作系统的操作。您可能会以一种非常有效的方式将内存从一个位置复制到另一个位置。如果我想复制这样的数组，我会在 java.lang.System 中寻找它
“我认为将这些方法放在原处的决定背后有一些逻辑。”
虽然这通常是正确的，但我发现当出现问题时，这种假设通常是你被误导的地方。
一种语言在不断发展，从有人提出一种新语言到它过时。在这些极端之间是语言经历的一些阶段。尤其是如果有人在它上面花钱并希望人们使用它，一个非常特殊的阶段经常发生，就在第一次发布之前或之后：
“我们需要这个昨天才能工作”阶段。
这就是发生这种情况的地方，您拥有几乎完整的语言，但是程序员需要做一些事情来展示该语言可以做什么，或者特定的应用程序需要该语言没有设计的功能。
那么我们在哪里添加这个功能呢？- 好吧，对于那个任务是“让它昨天工作”的特定程序员最有意义的地方。
逻辑可能是，这是函数最有意义的地方，因为它不属于其他任何地方，也不值得拥有自己的类。也可能是这样的：到目前为止，我们从来没有在不使用 system 的情况下完成数组复制。让我们将 arraycopy 放在那里，并为每个人节省一个额外的包含。
很久以后，如果有人愿意清理它，它将被标记为已弃用并删除..