openjdk-8 package in Ubuntu 20.04 LTS no longer updated?

Asked by Florian Bosch

Why is it that the 'openjdk-8' package in Ubuntu 20.04 LTS is no longer kept up-to-date with the latest "patch" (update) version of Open JDK 8, even though Ubuntu 20.04 LTS is supposed to get full support until Apr 2025?

The latest version of OpenJDK 8, at the time of this writing, is 8u302, released on July 20th 2021:
https://wiki.openjdk.java.net/display/jdk8u/Main

However, the 'openjdk-8' package in Ubuntu 20.04 LTS seems to be stuck at version 8u292 ?!?

Regards.

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu openjdk-8 Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Bernard Stafford (bernard010) said :
#1

I read your bug report. Debian has the current version as an obsolete package.
Ubuntu derives from Debian.
https://packages.debian.org/buster/nvidia-openjdk-8-jre
I do not see a backport listed for openjdk-8.
My suggestion is to use: openjdk-11-jre
There are no CVE's listed.
https://packages.ubuntu.com/focal/openjdk-11-jre

Revision history for this message
Florian Bosch (spattent) said (last edit ):
#2

It is actually not "my" bug report. And, according to the bug report, OpenJDK 8u302 does fix some CVEs. Furthermore, the bug report says that "once those issues are resolved and the new version is available in Ubuntu Impish (the current development release), it will also be added as updates for older Ubuntu releases." For some reason this doesn't seem to have happened.

Note: I have applicaton that needs Java 8 and cannot migrate to Java 11 right now. OpenJDK 8 has security support until Mar 2025, so should be kept up-to-date in LTS release of Ubuntu, I suppose!

Revision history for this message
Manfred Hampl (m-hampl) said :
#3

Possibly a limiting factor:
openjdk-8-jre-headless 8u302-b08-0ubuntu2 (amd64 binary) in Ubuntu impish requires (as dependency) the installation of libc6 (>= 2.34)
but Ubuntu focal has only libc6 version 2.31
I assume that this requires an in-depth checking for the cause of the higher version in the dependency and does not allow a "simple" backport.

Can you help with this problem?

Provide an answer of your own, or ask Florian Bosch for more information if necessary.

To post a message you must log in.