Get the damn memo already: Java11 reached end-of-life years ago

Photo by Chevanon Photography: https://www.pexels.com/photo/person-performing-coffee-art-302899/

I really dislike the uninformed attitude of some companies to the dependencies of their software. In this case: Rundeck
They actually state the following in their installation documentation:

Rundeck depends on Java 11. The Java 14 packages will satisfy this dependency however Rundeck will not function properly with them. It is recommended to install the openjdk-11-jre-headless package manually.
Source: https://docs.rundeck.com/docs/administration/install/linux-deb.html

In case Pagerduty (who owns Rundeck) didn't get the memo: Java11 reached end-of-life years ago! And some Linux distributions don't have packages for it any more. The latest Java version is Java22. And the current LTS version is Java21.

Utilizing https://endoflife.date/ we can easily get an overview of the respective dates.

Free builds from Oracle: https://endoflife.date/openjdk-builds-from-oracle: End of life reached: 19th March, 2019.

Paid builds from Oracle: https://endoflife.date/oracle-jdk: Premier Support reached end-of-life on 30th September 2023. Extended Support last until 31th January 2032.

RedHat builds of OpenJDK: https://endoflife.date/redhat-build-of-openjdk: Support ends 30th October 2024. With paid extended life-cycle support 1 it ends 31th October 2027.

However this is just for the OpenJDK packages!

The really important part is: Are there any Java11 packages for the operating system being used?

RedHat Linux Enterprise Server 9 contains Java1.8, Java11 and Java17.

SuSE Linux Enterprise Server 15 SP6 contains Java1.8, Java11 and Java17.

Ubuntu 24.04 - the current LTS version, provides OpenJDK packages for version 11, 17 and 21.

Debian Stable (Bookworm currently) ships with OpenJDK 17 only.

Sure, there are backports available for Debian, or you can just build your own packages. But that is not what bothers me. Java11 was released in September 2018. That is about 6 years ago. Java14 was released in March 2020. Four years ago.

And in all these years, they haven't been able to update their commercial application to depend on a more recent version of Java? Which is included in more recently released distributions? Or least make it work with them? This annoys me. Yes, it's nice that you offer free community packages for non-commercial distributions - but if I can't install your software because of missing dependencies, it doesn't help at all.

Especially as many business customers run commercial Linux distributions such as RedHat Linux Enterprise Server (RHEL) or SuSE Linux Enterprise Server (SLES) and are required to update regularly. Either by their own processes & standards or by law/insurances.

They literally can't install or even run older, unsupported versions of Java11 packages. This effectively forces them to purchase additional support packages for older versions of Java. Great! Not to mention if RHEL or SLES were to drop Java11 support. (Well, at least OpenJDK11 is already somewhat confirmed for RHEL10. Though I don't know if only with a valid ELS subscription or not. SuSE has not said anything about Java11 and SLES16 as far as I know).

Or they run one of the big non-commercial distributions like Debian or Ubuntu. Sure, Ubuntu 24.04 would be a viable alternative. But what if the customer doesn't have any Ubuntu servers? Should there be one or two Ubuntu servers out of thousands, just for one meagre application?

Create completely new Ansible playbooks and/or Puppet modules just for a handful of servers running a completely different OS? Maybe even use different software for other basic tasks like backup, LDAP integration, etc. in case the current software doesn't support Ubuntu LTS? This can easily lead to a long (and expensive) software chain reaction. Not to mention the new skills required at staff level.

"Just use docker."

You do understand that Docker is no solution to security risks when the container runs the same outdated software, yes? Sure it's good for mitigation/reduction of the attack surface but it doesn't fix the underlying problem.

And this annoys me. We really should hold enterprise software accountable to higher standards.

I do understand fairly well that someone at Pagerduty must have thought: "Well, all major (commercial) Linux distributions still support Java11, so there is no business risk for us. And for the rest we just provide container images via Docker." Yep, this is the reason why we sometimes can't have nice things. Total neglect of the wider responsibility while additionally ignoring the fact that Java11 needs to be included in all these commercial distributions as still too many software products rely on it.

If you sell software, every process involved in creating that piece of software should be treated as part of your core business and main revenue stream. Giving it the attention it deserves. If you don't, I'm going to make a few assumptions about your business. And those assumptions won't be favourable.

Unfortunately, this form of critical thinking about software dependencies is eroding as "Just use Docker" becomes the new norm among the next generation of IT professionals.