在研究标准 Java 库及其类时，我不禁注意到其中一些类的方法在我看来与这些类的原因几乎没有任何关系。
我所说的方法例如是 Integer#getInteger ，它检索某个“系统属性”的值，或 System#arraycopy ，其用途由其名称明确定义。 不过，这两种方法似乎都有点不合适，尤其是第一个方法，由于某种原因，它将系统资源的使用绑定(bind)到原始类型包装类。
从我目前的观点来看，这种方法放置策略看起来违反了基本的 OOP 设计原则:每个类必须致力于解决其特定的一组问题，而不是把自己变成一把瑞士军刀。 但由于我不认为 Java 设计者是白痴，所以我认为将这些方法放置在它们所在的位置的决定背后有一些逻辑。因此，如果有人能够解释这个逻辑到底是什么，我将不胜感激。
谢谢!
更新
一些人暗示 Java 确实有一些不合逻辑的东西，这些东西只是动荡的过去的残余。然后我重新阐述我的问题:为什么 Java 如此不愿意将其架构缺陷标记为已弃用，因为现有的已弃用功能并不可能在任何可观察到的 future 中停止使用，并且使某些内容弃用确实有助于避免在新的环境中使用它们创建代码？
最佳答案
这是一件值得思考的好事情。我知道最近的功能(例如泛型、lambda 等)，邮件列表上有几个博客和帖子解释了库创建者所做的选择。这些读起来非常有趣。
就你的情况而言，我希望答案不会太令人兴奋。制作它们的原因很难说。但这两个类从 JDK1.0 就存在了。在那些日子里，总体编程质量(尤其是 Java 和 OO)可能较低(这意味着通用实践较少，库创建者必须自己发明许多范例)。当时还存在其他限制，例如对象创建成本高昂。
许多设计笨拙的方法和类现在有了更好的选择。 (参见 Date 和包 java.time )
您希望添加到 Arrays 的 arraycopy类，但不幸的是它不存在。
理想情况下，原始方法将被弃用一段时间，然后删除。许多图书馆都遵循这一策略。然而，Java 对此非常保守，只弃用那些真正不应该使用的东西(例如 Thread.stop() 。我不认为 Java 中的方法曾因弃用而被删除。这意味着升级你的方法相当容易软件升级到较新版本的 Java，但这是以在库中留下一些困惑为代价的。
事实上，java 在保持新的 JDK/JRE 版本与旧的源代码和二进制文件兼容方面如此保守，让人又爱又恨。对于您的爱好项目或积极开发的小型项目来说，升级到新的 JVM 并在几年后删除已弃用的功能并不是太困难。但不要忘记，许多项目没有积极开发，或者开发人员很难安全地进行更改，例如因为他们缺乏适当的回归测试。在这些项目中，API 的更改需要花费大量时间来遵守，并且存在引入错误的风险。
此外，库经常尝试支持旧版本的 Java 以及新版本，当方法被删除时，它们会遇到问题。
关于java - 为什么标准类有时具有看似不相关的方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28958953/