我很熟悉.NET，知道补丁和升级对于框架版本（1.x）和（2.x / 3.x）和（4.x）是互斥的。 这种隔离使得理解依赖关系变得容易。
什么逻辑或隔离适用于Java升级？ 我什么时候该做，或者什么时候不应该？
一如既往的答案是“它取决于”。
如果你是一个消费者，补丁是安全相关的，现在就做。
如果您是一家企业，并且正在运行应用程序服务器，并且修补程序详细信息没有提到您可能遇到的安全漏洞（用户运行恶意的JNLP应用程序），那么您可以延期。 如果“补丁”添加了Java 1.6.0 Update 10（更新N）等新function，那么您也许可以延期。
一般来说，对某个Java版本（1.4.2,5,6,7）的更新应该是API稳定的，可以更新，但取决于你的应用程序对java的操作，你可能需要testing或者搁置。
例如最近Oracle在一个补丁中改变了一些关于HotSpot VM的元数据，导致Eclipse IDE失败。
100个Java补丁中的99个应该是API稳定的，并且具有不间断的变化。
许多需要特定Java版本的应用程序版本通常包含该版本的Java二进制文件及其应用程序，并启动它是<-lots-of -switches>的一些变体。
在上面的例子中，升级一般的/系统范围的/默认的java通常不会对具有它自己的java二进制文件的应用程序产生影响。 另一方面，除非您实际使用软件清单应用程序进行测量和报告，否则当您更新系统默认java时，您可能还不知道应用程序特定版本的Java（具有已知漏洞）。
次要更新通常是错误修复和安全更新，因此应始终应用它们。 任何与外部世界通信的Java虚拟机（Web服务和客户机）都会特别关心这一点。 主要更新（1.5至1.6,1.6至1.7）通常与早期版本向后兼容。 这是Java自成立以来一直非常可靠的事情。
向前兼容通常是主要关心的问题，而依赖于新Java特性（例如，Java 5generics，Java 6注释，Java 8 lambdaexpression式）的应用程序或平台（例如Eclipse，Tomcat）通常会推动主要平台升级在我们的商店。 举个例子，你可能会发现，自从过去几个月以来，Java 6客户端突然无法访问某些HTTPS网站，原因是响应了logjam SSL漏洞 ，该漏洞已经促使许多networkingpipe理员将他们的SSL证书升级到2048位密钥， Java 6不支持的大小，而是Java 7和8支持的大小 。
过去，一般有三到五年的时间，通常使用两三种不同的主streamJava版本，直到上面列出的一些关键特性提示转向新版本。
我们的开发环境仍然针对Java 6（针对较老的OS X客户端），针对新开发的Java 7以及针对我们的服务器环境的Java 8。 基本上，我们需要一个稳定的基于Java 8的生产环境，然后才能在开发环境中依靠Java 8function。 Java的向后兼容性使我们有很长的时间来进行这种转换。
对于Java 6，我相信缺乏1024DH的支持是棺材中的钉子。