When is Java 6 end of life? (In the context of writing developer tools)
Background
This is not as immediately obvious to figure out as you would think.
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.
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!)
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?
Finally we have OpenJDK... which Red Hat have said they will now be supporting...
And I am not even getting started on considering the other JVM implementations only the more common ones seen in the wild!
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:
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
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
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?
My real interest is when can developer tools advance their minimum Java version.
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 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 is moving to a 1 and three back policy in terms of
-sourceand-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.
Question
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?
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.
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.
Update 2: This should, as framed, be an answerable question based on fact. The correct answer should be either of the form
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.
or
Yes there is a definitive date of YYYY-MM-DD and here is the evidence
Answer
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?
No. There is no such date.
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.
(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.)
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 commented:
The OSS community cannot enter into support contracts.
That is completely wrong.
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.
Furthermore, all of the mainstream OSS licenses allow this ... including the GPL and all of its variants.
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.
That is also wrong.
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.)
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 ...