Java 6何时终止？（在编写开发人员工具的上下文中）

Question

想像中的不是那么显而易见。

首先，虽然Oracle从2013年2月起停止了对Java
6的公共支持，
但是Premier支持到2013年12月为止，而Extended支持到2016年12月才有了长尾巴。最重要的是，可持续支持可能永远持续下去。

下一个主要的Java供应商IBM 似乎尚未发布对Java
6的支持终止
（并且在2013年9月之前仍将支持Java
5！）。

第三，我们拥有Apple：随着2013年6月最新补丁的发布，而且由于“该公司没有拼写黑白支持政策”，这似乎是所有人的猜测……但是，如果他们处理Java 5，可以以此为基础，我们可能还会看到18个月左右的时间… 2014年底？

终于我们有了OpenJDK … Red Hat表示他们现在将支持 …

而且，我什至没有开始只考虑在野外看到的更常见的其他JVM实现！

因此，据我所知，到目前为止，只要您有钱支付Oracle / IBM / Red Hat，您就可以继续获得无限支持的Java 6版本…

也许我们可以开始更好地解决这个问题，并有机会获得一个不确定的答案：

• 如果您不能再购买特定JVM可以在其上运行的硬件/操作系统，那么继续支持该特定JVM就是一个小问题。扩展的支持合同是针对现有客户的，这些客户很可能通过现有系统满足了他们的现有需求……并且如果他们不能更改为较新的客户

实际上，这为我们提供了有关Apple的信息…由于Apple硬件已获得5年的支持（如果在加利福尼亚州，则为7年），因此唯一支持的Apple硬件应该是基于x86的硬件，因为该切换已于2006年12月完成（是最后一个基于PPC的苹果硬件），因此实际上我们不必担心在PPC上运行的Apple
Java版本，例如

同样，我们可以排除在旧版Windows上运行的所有Java版本。这意味着，如果Java安装程序无法在Windows
7+上运行，那么在2014年4月，那么我们可以有效地忽略Windows XP支持的Java版本吗？

• 我真正的兴趣是什么时候开发人员工具可以提高其最低Java版本。

Jenkins一直保持对Java
5的支持，但是较新的更改意味着1.520+在主服务器和从属服务器上需要Java 6或更高版本。如果某些构建从属（例如，旧硬件）无法运行较新的JVM，则可能导致问题。

Maven拥有悠久的历史，可以让您将JVM降级到J2SE
1.3来运行单元测试，但是从Surefire
2.15开始，它将仅支持在Java
5上运行的单元测试。

Javac在-source和-target…
方面正朝着1和3的方向发展，因此我们将需要等到JDK
10才从Javac中删除Java 6源文件支持…并计划了2年的发布节奏和Java 8
2014年初发布，这意味着JDK9将在2016年初，JDK10将在2018年初…但是JDK9可以公开维护另外3年，这意味着在2019年的某个时候，JDK
6源代码的兼容性可能会下降。

题

是否有明确的日期可用来确定OSS开发人员工具链何时可以放弃对Java 7之前的JVM的支持，那是什么日期？

OSS的区别很重要，因为OSS开发人员通常没有资金购买扩展/高级/可持续类型的支持合同，并且很可能无法使用晦涩/大型机硬件。

更新： 通过“放弃对Java 7之前的JVM的支持”，我的意思是可以安全地编译整个工具链，-target 7即字节码 需要 Java
7才能运行。

更新2： 按照框架，这应该是基于事实的可回答问题。正确答案应为以下形式之一

没有明确的答案，这是“一些人在Java 6上为OSS人们提供免费更新的链接”，他们没有说何时停止。

要么

是的，有一个确定的日期YYYY-MM-DD，这是证据

Answer 1

是否有明确的日期可用来确定OSS开发人员工具链何时可以放弃对Java 7之前的JVM的支持，那是什么日期？

不，没有这样的日期。

开发工具链的人可以在愿意或根本不愿意时放弃对EOL版本的Java的支持。假设地，如果个人（或公司）与其他公司（例如客户）订立了合同安排以提供给定期间的支持，那么这些协议显然会限制他们。但是，这不太可能限制整个项目。

（但是，实际情况是维持对旧版本Java的支持变得越来越难。开发人员希望/需要能够在工具链代码库中使用Java的新功能。因此，您很可能会看到可以使用工具链为旧版Java开发代码，但您必须在现代Java上运行该工具链。）

对于OSS版本的Java代码库，您（Java的用户）处于更好的位置：

• 很可能会在一定程度上获得社区的支持/发展，而这在商业上是可行的。

• 如果没有，您就可以访问源代码，因此（理论上）您可以自力更生，或花钱找其他人为您服务。

史蒂夫·科诺利（Steve Conolly）评论：

OSS社区无法签订支持合同。

那是完全错误的。

OSS社区中的任何人都可以与您签订合同以提供对OSS产品的支持。实际上，这就是一些开发人员赚钱的方式，使他们能够继续开发自己的东西。

此外，所有主流OSS许可都允许这样做…包括GPL及其所有变体。

但是，如果OSS社区无法发展开发人员，因为您不能在不增加成本的情况下完全访问该技术，那么这将迫使Java 7之前的支持成为不可能。

这也是错误的。

Sun（以前）和现在的Oracle免费提供EOL版本的Java免费版本的下载…一直到Java 1.1。EOL-
ing不会更改可用性。实际上，这与旧版Java修补程序版本的可用性有关，以解决最近发现的安全问题和其他错误。您必须为此付费。（足够公平。完成这项工作要花Oracle钱。）

问题是Java 5和更早版本曾经以自由形式免费提供。这意味着，在Java 5中，客户实际上没有选择（修复）安全漏洞的 选择 。相比之下，在Java
6中，客户确实 具有该选择 。OpenJDK 6代码库已作为开放源代码发布， 无法 取消。而且，由于Java 7和Java
8也是开源的，因此人们可以跟踪Java 7和8中的安全修复程序，并尝试将所做的更改回移植到OpenJDK 6代码库中。