search

adoptium / containers

Repo containing the dockerfiles and scripts to produce the official eclipse-temurin containers.
https://hub.docker.com/_/eclipse-temurin/
Apache License 2.0
206 stars 87 forks source link

armv7 docker images for OpenJDK 21 #502

Closed bbernhard closed 3 months ago

bbernhard commented 4 months ago

Hi,

first of all, I would like to thank you for all the great work you are doing - I am using the armv7, arm64 and amd64 docker images since a few years and it's working great. Thanks a lot for maintaining the docker images - very much appreciated!

Recently I wanted to upgrade to OpenJDK 21 and noticed that there are no armv7 images for that, so I wanted to ask whether there's a specific (technical?) reason for why they are missing or if there are any plans to add them?

Thanks, Bernhard

karianna commented 4 months ago

Unfortunately armv7 (arm32) is no longer supported from Java 21 onwards by the upstream OpenJDK project or our downstream version

bbernhard commented 4 months ago

Unfortunately armv7 (arm32) is no longer supported from Java 21 onwards by the upstream OpenJDK project or our downstream version

That's a pity - especially, as there are a lot of Raspberry Pi's out there, which are perfectly capable of running Java applications. I couldn't find any official information from the OpenJDK project that the armv7 support is now dropped - just out of curiosity, do you maybe have a link to that announcement? I am wondering, because all bigger distros (like Debian, Arch und Ubuntu) still provide OpenJDK 21 packages for armv7.

karianna commented 4 months ago

Hmm, got myself mixed up with another platform. I think it's just us not currently supporting them. https://github.com/adoptium/temurin-build/issues/2078 is traxking reenabling this.

@sxa might have more details

sxa commented 4 months ago

Hmm, got myself mixed up with another platform. I think it's just us not currently supporting them. https://github.com/adoptium/temurin-build/issues/2078 is traxking reenabling this.

@sxa might have more details

That issue predates JDK21 and seems to be a general issue relating to testing on Arm32 and is no longer relevant.

sxa commented 4 months ago

Recently I wanted to upgrade to OpenJDK 21 and noticed that there are no armv7 images for that, so I wanted to ask whether there's a specific (technical?) reason for why they are missing or if there are any plans to add them?

Hi Bernhard, thanks for your kind words about the project. . https://github.com/adoptium/adoptium-support/issues/962 is the issue where this was discussed. The initial versions of JDK21 had failed which meant we couldn't ship, but (which have now been resolved) but ultimately the PMC considered it to not be sufficiently well supported any more (One person on the upstream jdk updated mailing list said they intended to try to "keep the lights on" but that was the extent of the commitment - it does still build and the 32-bit code has not yet been removed from the codebase) and none of our Working Group members expressed any desire to continue with it for 21+.

I did propose keeping it as an untested "evaluation" for now like Windows/Arm64 and Linux/riscv64 but that was rejected - ultimately that should only be for platforms we are looking to get to a GA state.

Out of interest, what is your use case for wanting 21 instead of 17 on that platform?

bbernhard commented 4 months ago

Recently I wanted to upgrade to OpenJDK 21 and noticed that there are no armv7 images for that, so I wanted to ask whether there's a specific (technical?) reason for why they are missing or if there are any plans to add them?

Hi Bernhard, thanks for your kind words about the project. . adoptium/adoptium-support#962 is the issue where this was discussed. The initial versions of JDK21 had failed which meant we couldn't ship, but (which have now been resolved) but ultimately the PMC considered it to not be sufficiently well supported any more (One person on the upstream jdk updated mailing list said they intended to try to "keep the lights on" but that was the extent of the commitment - it does still build and the 32-bit code has not yet been removed from the codebase) and none of our Working Group members expressed any desire to continue with it for 21+.

I did propose keeping it as an untested "evaluation" for now like Windows/Arm64 and Linux/riscv64 but that was rejected - ultimately that should only be for platforms we are looking to get to a GA state.

Out of interest, what is your use case for wanting 21 instead of 17 on that platform?

Hello Stewart,

thanks a lot for your detailed answer!

I am the maintainer of signal-cli-rest-api which is based on the upstream project signal-cli. Recently the maintainer of signal-cli released a new version which requires Java 21. I think they did it, because their upstream project switched to Java 21.

The docker container I am maintaining is built for amd64, arm64 and armv7 and I want to keep the support for all this architectures alive as long as possible. Especially, as I know that a lot of users use some older Raspberry Pi models to run the docker container on (either standalone or together with some other applications like Home Assistant).

As the Raspberry Foundation is still supporting all their models with an up to date OS, I think those small computers are great for those kind of applications and it would be a pity to drop support for them.

sxa commented 4 months ago

I think they did it, because their upstream project switched to Java 21.

Thanks for the input - that's interesting to know from someone with a hard requirement to run JDK21 on such devices. I haven't heard of many projects switching to mandating 21.

I think those small computers are great for those kind of applications

Yeah makes sense - I have a pile of pis around and also a couple of ODROID-HC1 8-core arm32 systems in active use :-)

sxa commented 3 months ago

I'm going to close this on the basis that docker images require us to have a build first, and the discussion on having a build has been happening in https://github.com/adoptium/adoptium-support/issues/962 so any discussion should be directed there.