As the relatively “new guy” to the Java SE PM team, I’m still finding my way around and learning lots as we go through various milestones after the Java SE 7 launch, and move onwards to Java 8. The recent update to the Java 6 public “End Of Life” date was pretty interesting to me, so I thought I’d share some of the more pedantic semantics, for those of you who might care.
The first thing to note is that EOL means end of public life. The version will still exist and be supported for many additional years, just not in the public. As with most free software, whether commercially licensed or Open Source, usually only one or two major streams are maintained – in the public – at a time. It’s a simple function of maintenance costs. It’s not reasonable to resource free ongoing development of five+ major release streams. For those who cannot keep up with current releases, and have a need for longer term support, paid options are available to defray the ongoing costs. It would also be confusing to end users trying to figure out which of 5 available versions to choose between. It’s confusing enough when there are 2!
Next, the EOL is not so much an single moment “event”, as it is a longer term process. When version X of Java is EOL’d in favor of version Y, the following process is what generally happens:
– Future notice is given to the community. As summarized in Henriks blog, a public EOL can be expected as soon as the latest of: 3 years after a major release; 1 year after a subsequent major release; 6 months after the subsequent major release is set as the default JRE on java.com.
– At some point after the above criteria are met, a final public release of version X is made available.
– The EOL version is still made available for download for at least a couple of months, after which it becomes archived. “Archived” means it’s still available, but usually only meant for developers that want to debug some old code, but is not suitable for general usage as it’s no longer publicly patched.
So while we might state a particular moment as the “EOL” of a major release, it is likely still to be publicly available (and the most current update available) for a period of time thereafter.
– Don
DonaldOJDK Blog 
I think one problem is that you are using the term Java EOL while you mean a specific Oracle product that happens to be an implementation of Java. It would really help if in these announcements it was made very clear this is about a specific Oracle Product and avoid the name Java if at all possible. There are lots of implementations for the java programming language all with their own “life cycles”. And now with OpenJDK there will probably be multiple organisations which will keep supporting various versions for various audiences.
I should have replied earlier, but I agree 100% with what you say and need to endeavor to be clearer with this distinction in the future.
I agree it is always helpful to avoid the bare term “Java”. FWIW, I tried very hard to keep a bright line between the Java SE platform and the JDK product in the compatibility notes at http://www.oracle.com/technetwork/java/javase/compatibility-417013.html. The difference can be pretty subtle.
Pingback: Donald Smith: EOL’ing a version of Java Is a... | JDK | Syngu
Pingback: Tab Sweep – ArchBeat java EE podcast, Safer JVM with OSGi, building EE artifacts with Maven, WebSocket vs. REST, Mojarra tests, … « oracle fusion identity
Pingback: EOLing Java SE 6, JavaFX 1.2, and JavaFX 1.3 « oracle fusion identity
Donald,
Can you tell know how much of the installed code base you are covering with the freely supported Java SE 7?
If all the other people need to pay for basic JDK updates (security fixes, OS upgrades…), can Java still be considered a free development platform?
Jan
I may need your help with some context. What are some other free (or even paid) products which maintain three or more major release streams at a time? I can’t really think of any, but would love to have some examples. I remember going through this at the Eclipse Foundation where only the most current release of the IDE is supported. Organizations that need longer term support for Eclipse than the most current release need to pay for it, and there’s some ongoing work to try to organize that support. It’s just not fair or reasonable to expect anyone, in any community, to support old software. The Java ecosystem is not used to this because it’s been a while with acquisitions and the like, but it’s time to get back in the habit.
– Don
Pingback: End of the road for java6 | Java PDF Blog
“…It’s just not fair or reasonable to expect anyone, in any community, to support old software….”
First of all, this is the software business, and life in the fast lane is not always “fair”.
But more importantly, when large business or government agencies develop applications that cost megabucks, it is “fair and reasonable” to expect this investment to last over a long time. Java has a habit of releasing (it seems) monthly. Sometimes a later release will break the application, and require much work and rework.
It is not only “fair and reasonable” that future versions are backwards compatible. We demand it.
Agreed!