什么时候Java 6生命终结？ （在编写开发人员工具的上下文中） [英] When is Java 6 end of life? (In the context of writing developer tools)

问题描述

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

This is not as immediately obvious to figure out as you would think.

首先关闭，虽然 Oracle已于2013年2月停止了对Java 6的公众支持，但Premier支持已经结束到2013年12月和2016年12月的扩展支持有一个长尾。最重要的是，持续支持可以持续下去。

First off, while Oracle has stopped public support of Java 6 as of Feb 2013 but with Premier support going out to Dec 2013 and Extended support going to Dec 2016 there is a bit of a long tail. On top of that there is Sustaining support which could go on for ever.

下一个主要的Java供应商，IBM，似乎甚至没有发布对Java 6的支持（并且仍然支持Java 5直到2013年9月！）

The next major Java vendor, IBM, does not seem to have even posted an end of support for Java 6 (and is still supporting Java 5 until Sep 2013!)

第三，我们拥有Apple：2013年6月的当前最新补丁以及该公司没有详细说明其黑白支持政策似乎是任何人的猜测......但如果他们处理Java 5可以作为我们可能会看到另外18个月左右的基础... 2014年底 - 是什么？

Thirdly, we have Apple: with the currently most recent patch in Jun 2013 and as "the company does not spell out its support policies in black and white" it seems to be anyone's guess... but if they handling of Java 5 can be used as a basis we may see another 18 months or so... end of 2014-ish?

最后我们有OpenJDK ......其中R ed Hat已经表示他们现在将支持 ...

Finally we have OpenJDK... which Red Hat have said they will now be supporting...

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

And I am not even getting started on considering the other JVM implementations only the more common ones seen in the wild!

所以从我所看到的，到目前为止，只要您有资金支付Oracle / IBM / Red Hat，您就可以继续获得无限期支持的Java 6版本...

So from what I can see, so far, as long as you have the money to pay Oracle/IBM/Red Hat you can continue to get a Java 6 version that is supported indefinitely...

也许我们可以开始更好地构建这个问题，并获得一个非无限期答案的机会：

Maybe we can start to frame this question a bit better, and get a chance at a non-indefinite answer:

• 如果你不能购买特定JVM运行的硬件/操作系统，然后继续支持那个特定的JVM是一个没有实际意义的点。扩展支持合同适用于现有客户，现有客户很可能已满足其现有需求......如果他们无法更改为更新

• If you cannot buy the hardware/operating system that the specific JVM runs on any more, then that specific JVM continuing to be supported is a bit of a moot point. The extended support contracts are for existing customers, who more than likely have their existing needs met by their existing systems... and if they cannot change to a newer

这实际上是给我们一些关于Apple的背景信息......由于Apple硬件支持5年（​​如果在加利福尼亚州有7个），那么唯一受支持的Apple硬件应该是基于x86的硬件，因为交换机是由 2006年12月（是最后发布的基于PPC的Apple硬件），所以实际上我们不必担心在PPC上运行的Apple Java版本， as

This actually gives us some context on Apple... as Apple hardware is supported for 5 years (7 if in California) then the only supported Apple hardware should be x86 based hardware as the switch was completed by Dec 2006 (being the last PPC based Apple hardware to ship), so in reality we do not have to worry about Apple Java versions that run on PPC, as

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

Similarly, we can probably rule out any versions of Java that run on older versions of Windows. Which means that come Apr 2014 if the Java installer will not run on Windows 7+ then can we effectively ignore that Java version being supported on Windows XP?

我真正感兴趣的是开发人员工具什么时候可以推进他们的最低Java版本。

My real interest is when can developer tools advance their minimum Java version.

Jenkins 保持对Java 5的支持已有一段时间了，但更新的更改意味着 1.520+ 需要Java 6或更高版本的主人和奴隶。如果某些构建从属服务器，例如，这可能会导致问题。遗留硬件，无法运行较新的JVM。

Jenkins has been maintaining support with Java 5 for some time, but newer changes mean that 1.520+ is requires Java 6 or newer on the master and the slaves. This can cause issues if some of the build slaves, e.g. legacy hardware, cannot run newer JVMs.

Maven 历史悠久让你将JVM分解为J2SE 1.3以运行单元测试，但是从 Surefire 2.15 开始，它只会支持在Java 5上运行单元测试。

Maven has had a long history of letting you fork a JVM down to J2SE 1.3 for running unit tests, but as of Surefire 2.15 it will only support running unit tests on as low as Java 5.

javac正在转向在 -source 和 -target 方面的1和3背政策...所以我们将需要等到JDK 10才能从javac中删除Java 6源文件支持...具有2年发布节奏和Java 8计划于2014年初发布，这将意味着2016年初的JDK9和2018年初的JDK10 ...但是JDK9将在公开维护3年后可用，这意味着2019年的某个时候可能会删除JDK 6源代码兼容性。

javac is moving to a 1 and three back policy in terms of -source and -target... so we will need to wait until JDK 10 before Java 6 source file support is dropped from javac... with a 2 year release cadence and Java 8 scheduled for release early 2014, that would imply JDK9 in early 2016 and JDK10 in early 2018... but JDK9 would be available with publicly maintained for another 3 years which means that some time in 2019 is when JDK 6 source code compatibility could be dropped.

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

Is there a clear date that can be used to establish when OSS developer toolchains can drop support for pre-Java 7 JVMs, and what is that date?

OSS的区别对于OSS很重要开发人员通常没有资金购买扩展/优质/维持型支持合同，很可能无法访问模糊/大型机硬件。

The OSS distinction is important as OSS developers typically do not have funding to purchase extended/premium/sustaining type support contracts and quite likely do not have access to obscure/mainframe hardware.

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

Update: By "drop support for pre-Java 7 JVMs" I mean that it would be safe to compile the entire toolchain with -target 7 i.e. that the bytecode requires Java 7 to run.

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

Update 2: This should, as framed, be an answerable question based on fact. The correct answer should be either of the form

没有明确的答案，这里是为OSS提供免费更新的一些人的链接人们使用Java 6他们还没有说他们何时会停止。

No clear answer, here is a link to "some people that are providing free updates for OSS people on Java 6" and they have not said when they will stop yet.

或

是的，确认日期为YYYY-MM-DD，这是证据

Yes there is a definitive date of YYYY-MM-DD and here is the evidence

推荐答案

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

Is there a clear date that can be used to establish when OSS developer toolchains can drop support for pre-Java 7 JVMs, and what is that date?

不。没有这样的日期。

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

The people developing tool chains are free to drop support for EOL'd versions of Java when they like ... or not at all. Hypothetically, if individuals (or companies) have entered contractual arrangements with other companies (e.g. customers) to provide support for a given period, then those agreements would obviously constrain them. However, it is unlikely that that will constrain the project as a whole.

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

(However, the practicalities are that maintaining support for older versions of Java gets harder and harder to sustain. Developers want / need to be able to use new Java features in the toolchain code-base. So you are likely to see cases where you can use the toolchain to develop code for legacy Java, but you have to run the toolchain on modern Java.)

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

In the case of OSS versions of the Java code base, you (the user of Java) are in a better position:

• 在商业上可行的情况下，很可能会有一定程度的社区支持/发展。

• There is likely to be a certain level of community support / development long past the point at which it would be commercially viable to do this.

如果没有，您可以访问源代码，这样您（理论上）可以自己支持，或者付钱给别人为您做。

And if not, you have access to the source code so you could (in theory) support yourself, or pay someone else to do it for you.

Steve Conolly评论：

Steve Conolly commented:

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

The OSS community cannot enter into support contracts.

这是完全错误的。

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

Anyone in the OSS community can enter into a contract with you to provide support for an OSS product. That's actually how some developers earn the money that allows them to keep developing their stuff.

此外，所有主流OSS许可都允许这样做......包括GPL和所有它的变种。

Furthermore, all of the mainstream OSS licenses allow this ... including the GPL and all of its variants.

但是如果OSS社区不可能增加开发人员，因为你根本无法访问技术而不会产生费用那么这迫使java-7之前的支持变得不可能。

But if it is not possible for an OSS community to grow developers because you cannot access the technology at all without incurring cost, then that forces pre-java 7 support as impossible.

这也是错误的。

Sun（之前）和现在的Oracle提供免费版本的Java免费版EOL版本......一直回到Java 1.1。 EOL-ing不会改变可用性。它实际上是关于最近发现的安全问题和其他错误的旧版Java补丁版本的可用性。你必须付钱。 （很公平。这需要Oracle资金来完成这项工作。）

Sun (previously) and now Oracle offer free downloads of EOL'd versions of the free versions of Java ... going all the way back to Java 1.1. EOL-ing does not change availability. It is actually about availability of patch releases of old versions of Java for recently discovered security issues and other bugs. You have to pay for that. (Fair enough. It costs Oracle money to do the work.)

问题是Java 5及更早版本是以源代码形式免费提供的。这意味着客户实际上没有选择在Java 5中修复（比如说）安全漏洞。相比之下，在Java 6 中，他们确实有这个选项。 OpenJDK 6代码库已作为开源发布，无法被撤销。此外，由于Java 7和Java 8也是开源的，人们可以跟踪Java 7和8中的安全修复程序，并尝试将更改反向移植到OpenJDK 6代码库...

The problem is that Java 5 and earlier were and are not freely available in source code form. That means that customers don't realistically have the option of fixing (say) security holes in Java 5. By contrast, in Java 6 they DO have that option. The OpenJDK 6 codebase has been released as open source, and that cannot be rescinded. And furthermore, since Java 7 and Java 8 are also open source, people can track security fixes in Java 7 and 8, and attempt to back-port the changes to the OpenJDK 6 codebase ...

这篇关于什么时候Java 6生命终结？ （在编写开发人员工具的上下文中）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！