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 ...
