This is possibly ok, actually. Java 9 and 10 have been released; Java 11, the next long-term-support release, has a release date of September. So this applies if you're on a 5-year-old version of Java and choose to run Java 8 rather than update to 11. http://openjdk.java.net/projects/jdk/11/

Java 9 was released end of September 2017... That's less than 1.5 years to migrate all your apps (possible many hundreds) from Java 8 to Java 9. Way too short.

In fact, Java 9 is already out of support (since last month). The next viable Java version after Java 8 is Java 11, which is an LTS version. Java 11 will come out around September this year. So in reality, this means organizations have a couple months to migrate everything from Java 8 to Java 11. Laughable.

This is all accurate. However, it is not like Java 9 was being developed in private, and I doubt many shops even started to look at support once it was RTM.

Java shops are used to being able to stay on old releases for near-forever, but they need to adapt to Oracle's business model being to charge for Java support. It was Sun's monetization model for Java too; they just sucked at it.

In addition to this, Java 9 introduces changes that make the migration non-trivial

YMMV but I would be hard pressed to name any company I produced Java-based software for which even ran Java 9.

What other runtime offers free LTS? Does Python? Does Node? Go? Erlang? Haskell? How is it getting fleeced to be able to buy (instead of get for free) something that others don't offer at all?

Python does LTS, although they don't explicitly call it LTS:

https://devguide.python.org/#status-of-python-branches

Each Python version is supported for 5 years. So if you start building on Python 3.6 you are guaranteed to have a supported version till 2021. Upgrade to 3.7 (due out in June) when released and you'll be set till 2023.

So yes, Python does offer free LTS.

And java 8 also has free support for 5 years (released Mar 18, 2014, free updates end on Jan 2019. (ok, 2 months short of 5 years.) The charging for support is for the stuff older than 5 years - that is the long-term support being charged for. This isn't anything new for Oracle or many other companies.

The problem is that you have very short window to migrate to Java 11 (next LTS) with Python there is no such problem as really each release is LTS, so you have three years to migrate from 3.6 to 3.7.

Er, hate to break it to you, but some of the ones you list actually do offer free LTS releases, e.g. Node: https://nodejs.org/en/download/

Node LTS has 30 month of support JDK 11 will have a similar one of three years. Less overlap though.

You could always use a language with a spec and multiple implementations. Common Lisp and C have both been around for a long time with specs that have seen wide open source and commercial implementation.

You're right, that's very generous. But as they don't maintain the VM and they don't have a big standard library, it's probably an order of magnitude cheaper than maintaining the JDK.

I can't think of any other popular language that requires payment for security updates. Node supports an LTS version, Python support for 2.7 extends to 2020 [1] despite Python 3 being released in 2008, Microsoft still provides support for .NET 3.5 Framework released in 2007. Java 9 was released in July, 2017 that's nowhere near sufficient time to force an upgrade.

This is just Oracle being Oracle and finding another way to fleece their Customers, many of which were Customers of Sun who would never pull a move with such contempt like this.

[1] https://www.python.org/dev/peps/pep-0373/

Ubuntu even provide an entire OS supported with security updates free of charge for five years. Granted, they have considerably more developers and commercial support from Canonical, but most of these languages have some kind of sponsorship deal in the background.

Definitely Oracle being Oracle.

Does the concept of LTS really make sense for languages that produce compiled executables? Taking Haskell as an example, the usual output may have dependencies on some typical system shared libraries, not so much on the ecosystem from which it was compiled. If static compilation is an option, then there is very little runtime dependency on anything besides the OS.

Now, there could be a vulnerability in one of the packages you built against, but exploitation of that is going to also depend on whether that specific program uses the vulnerable bits of code, using inputs controllable by an attacker.

It's mostly moot compared to the story here anyway, as none of the others are beholden to any entity resembling Oracle.