我对 .NET 非常熟悉，并且知道修补程序和升级对于框架版本 (1.x) 和 (2.x / 3.x) 和 (4.x) 是互斥的。这种隔离使人们很容易理解依赖关系。
实施 Java 升级时应遵循哪些逻辑或分类？我什么时候应该这样做，什么时候不应该这样做？
答案1
一如既往，答案是“视情况而定”。
如果您是消费者并且补丁与安全相关，请立即执行。
如果您是一家企业，并且正在运行应用程序服务器，而补丁详细信息未提及您可能遇到的安全漏洞（用户运行恶意 JNLP 应用程序），那么您可以暂缓使用。如果“补丁”正在添加新功能，例如 Java 1.6.0 Update 10（更新 N），那么您可以暂缓使用。
一般来说，对某个 Java 版本（1.4.2、5、6、7）的更新应该是 API 稳定的并且可以更新，但根据您的应用程序对 Java 的操作，您可能需要测试或推迟。
例如最近 Oracle 在补丁中更改了有关 HotSpot VM 的一些元数据，这导致 Eclipse IDE 失败。
在 100 个 Java 补丁中，99 个都应该是 API 稳定的，并且不会产生重大变化。
答案2
许多需要特定 Java 版本的知名应用程序版本通常在其应用程序中包含该版本的 Java 二进制文件，并且启动它是 <-lots -of -switches> 的一些变体。
在上述情况下，升级通用/系统范围/默认 Java 通常不会对具有其自己的 Java 二进制文件的应用程序产生影响。另一方面，当您更新系统默认 Java 时，您可能也不知道特定于应用程序的 Java 版本（具有已知漏洞）存在，除非您实际上正在使用软件清单应用程序对其进行测量和报告。
答案3
次要更新通常是错误修复和安全更新，因此应始终应用它们。对于与外界（Web 服务和客户端）通信的任何 Java VM，这尤其令人担忧。主要更新（1.5 到 1.6、1.6 到 1.7）通常与早期版本向后兼容。这是 Java 自诞生以来一直非常可靠的一点。
向前兼容性通常是主要关注点，而依赖于新 Java 功能（例如 Java 5 泛型、Java 6 注释、Java 8 lambda 表达式）的应用程序或平台（例如 Eclipse、Tomcat）通常会推动我们商店进行重大平台升级的决定。举个例子，您可能会发现 Java 6 客户端在过去几个月里突然无法访问某些 HTTPS 网站，原因是对僵局 SSL 漏洞，这促使许多网络管理员将其 SSL 证书升级为 2048 位密钥，这种密钥大小Java 6 不支持，但 Java 7 和 8 支持。
过去，通常会有三到五年的时间，在此期间，两个或三个不同的主要 Java 版本会被广泛使用，直到某些关键特性（如上面列出的特性）促使人们转向新版本。
我们的开发环境仍然以 Java 6 为目标（适用于较旧的 OS X 客户端），Java 7 用于新开发，Java 8 用于我们的服务器环境。基本上，我们希望在开发环境中开始依赖 Java 8 功能之前，有一个基于 Java 8 的稳定生产环境。Java 的向后兼容性让我们有足够的时间进行这种转变。
对于 Java 6，我认为缺乏 1024DH 支持是致命的。