18

背景

这并不像你想象的那么明显。

首先，虽然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 Apple 硬件），因此实际上我们不必担心在 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 在和方面正在转向 1 和 3 后退-source政策......-target所以我们需要等到 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，这是证据

4

1 回答 1

13

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

不，没有这样的日期。

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

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

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

  • 很可能会有一定程度的社区支持/发展，远远超过这样做在商业上可行的程度。

  • 如果没有，你可以访问源代码，这样你就可以（理论上）养活自己，或者付钱给别人为你做。

史蒂夫康诺利评论道：

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 代码库......

于 2013-07-16T09:02:57.337 回答