18

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

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

Michael-O
  • 18,123
  • 6
  • 55
  • 121
Stephen Connolly
  • 13,872
  • 6
  • 41
  • 63
  • 3
    When will Java 5 end? :) – JIV Jul 16 '13 at 08:46
  • 1
    @JIV: When will Java 1.4 end?! – Joachim Sauer Jul 16 '13 at 08:46
  • I'm afraid this will end up mostly opinion-based, because it's mostly about trade-offs. Also: are you talking about *running* on Java 6 or *manipulating* Java 6 code? It's less of a problem if your tool needs Java 7 to run. It *might very well* be a problem if it only produces/handles/understands Java 7 code. – Joachim Sauer Jul 16 '13 at 08:48
  • Which is why I tried to frame the question as a "No here is the why not/Yes here is the why and the date" rather than the more generic... but yeah there is risk of an element of opinion in this question – Stephen Connolly Jul 16 '13 at 08:50
  • End of public update for java 7 support is July 2014. But there is no clearance about the End of support date for oracle 7. – MGPJ Jul 16 '13 at 08:53
  • @muniganesh but if OSS developers are not able to purchase such support it is a moot point. I am trying to frame this as a non-opinion based answerable question – Stephen Connolly Jul 16 '13 at 08:54
  • 1
    +1 for the summary of JVM support option s – Eli Algranti Jul 16 '13 at 23:06

1 Answers1

13

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

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • The OSS community cannot enter into support contracts. So as such they are irrelevant. And certainly people developing toolchains are free to drop support earlier. 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. It does not mean there is a clear date though! – Stephen Connolly Jul 16 '13 at 09:07
  • Take Maven as an example. If you need to build on Java 1.4 you can currently either: limit yourself to Maven 2.0.11 or older; or any currently released Maven, toolchains and limit yourself to Surefire 2.14.1 or older. So there is a path using older versions of Maven to build. But at some point there is no way you can expect the Maven developers to be able to continue to test Maven on JDK 1.5. (right now we can use MSDN license (thanks Microsoft for providing free to Apache projects), virtualization and old Java releases to get down to 1.5) – Stephen Connolly Jul 16 '13 at 09:12
  • The Maven example is in line with what I wrote. The reality is that the official Maven project's support for older Java platforms will decrease, and will probably cease. But even if it does, you still have the option of self support ... or hiring someone (possibly even one of the core developers). It is amazing what people will do for (enough) money. – Stephen C Jul 16 '13 at 09:17
  • Ok, revised answer I think is a good one. – Stephen Connolly Jul 16 '13 at 09:57
  • Just realised that there may be some confusion about my "OSS community cannot enter support contracts" statement. By that I mean that in general, the volunteer OSS community members cannot *purchase* support contracts. OSS foundations may be *granted* such support, or may use funding to purchase support for their members, but that is relying on good will / a questionable use of their funds respectively... Hence the OSS community is effectively locked out. – Stephen Connolly Nov 09 '13 at 10:24
  • 2
    The people who really need the patches are organizations that are *running* production systems on EOL'ed platforms. The security patches are largely irrelevant for OSS developers who are trying to keep their code runnable on EOL'ed releases. The real reasons an OSS project is going to drop support are: 1) the old platforms are holding the project back, and 2) the decreasing number of users on those platforms makes it not worth the effort. – Stephen C Jul 16 '14 at 11:34