Java 21 for 32-bit: Add BellSoft Liberica JDK 21

[holgerfriedrich]

Java 21 until now required a native 64 bit installation, as we did not have a provider for JDKs for 32-bit systems.
I found a provider for a JDK, which also runs on 32-bit systems.

This removes a big blocker for introducing Java 21 on more systems, as we can still support 32-bit hardware and the JDK can be installed on existing installations without much effort.

I have no experience with the BellSoft Liberica JDK until now. Maybe someone else knows these JDKs and can give some input.

On my test system (RPi 4, 32-bit) OH seems to start up fine.

[mstormi]

@ecdye Java is your playground, isn't it

[ecdye]

I suppose so, I'll take a look.

[ecdye]

Overall, it looks pretty good. I haven't tested it to make sure that it works. Holger, have you verified that this installs and runs properly?

[holgerfriedrich]

Overall, it looks pretty good. I haven't tested it to make sure that it works. Holger, have you verified that this installs and runs properly?

I have tested the installation when I created the PR. It ran fine on my test system, openHAB started successfully.
Though, it did not get any mileage, as I typically run my PIs on 64-bit OS with a 64-bit Java.

I have not worked with this JDK before - but it is the first I came across which does provide Java 21 for 32-bit RPi.
Having no JDK for 32-bit ARM could be a real blocker when we think about lifting minimum Java version to Java 21 in the future.

[holgerfriedrich]

Hi, @wborn, do you have by chance any experience with BellSoft Liberica JDK?
It is the first JDK I came across which does provide Java 21 for 32-bit RPi.

[ecdye]

Hi, @wborn, do you have by chance any experience with BellSoft Liberica JDK? It is the first JDK I came across which does provide Java 21 for 32-bit RPi.

I can second that, I did just a little research and couldn't really find any other vendors that were providing one in general. It seems Java has finally started to join with the industry in moving towards complete migration to 64 bit, which I am still not sure about personally.

[ecdye]

LGTM, I'll wait to merge unit we hear back from Wouter as I am curious of his input.

[wborn]

do you have by chance any experience with BellSoft Liberica JDK

I didn't know it existed until now. 😉 Looks like it's currently the only 32-bit Java 21 JVM out there. Maybe Azul eventually creates one as well when several paying customers ask for it.

[ecdye]

Fair enough, I think it's good enough that we can merge it have experimental support for it for now.

[florian-h05]

Just stumbled across this PR ... I am pretty surprised that there is a JDK 21 for 32-bit ARM.
I am no really fan of this however, as JDK 17 will not become EOL not before September 2026, and IMO after Sep 2026 (we need to release an openHAB 5 with JDK 21 requirement before JDK 17 EOL) we should abolish 32-bit ARM support, at least partly.
Having to keep 32-bit arm support in 2026 and afterwards IMO is a IMHO unneccassary maintenance burden.

FYI, keeping 32-bit ARM support holds me off from upgrading GraalJS to recent versions, which would however be good from a functionality and security POV.

[holgerfriedrich]

I see. There is also some benefit getting rid of 32-bit systems in the future.

On the other hand, I see some benefit moving towards Java21 way before EOL on Java17. For example, virtual threads could improve our resource consumption.

I always assumed we have a huge user base still using older RPIs. I remember a lot of discussions about tuning openHABian for such machines.

Give me some time, I will open an issue to discuss possible paths towards Java21.

[mstormi]

I believe there's many RPi3 in operation. They can do 64, but that requires so much more memory than 32 that  RAM becomes an issue on these boxes.Plus, some people still run even older systems that technically cannot do 64.Do you want to abandon HW support for those?what's wrong with providing a 32bit Java why does that increase support needs?(well for me in openHABian it does, but why in programming?)Am 03.10.2024 15:19 schrieb Holger Friedrich ***@***.***>: I see. There is also some benefit getting rid of 32-bit systems in the future. On the other hand, I see some benefit moving towards Java21 way before EOL on Java17. For example, virtual threads could improve our resource consumption. I always assumed we have a huge user base still using older RPIs. I remember a lot of discussions about tuning openHABian for such machines. Give me some time, I will open an issue to discuss possible paths towards Java21. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***> Am 03.10.2024 15:19 schrieb Holger Friedrich ***@***.***>: I see. There is also some benefit getting rid of 32-bit systems in the future. On the other hand, I see some benefit moving towards Java21 way before EOL on Java17. For example, virtual threads could improve our resource consumption. I always assumed we have a huge user base still using older RPIs. I remember a lot of discussions about tuning openHABian for such machines. Give me some time, I will open an issue to discuss possible paths towards Java21. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***> Am 03.10.2024 15:19 schrieb Holger Friedrich ***@***.***>: I see. There is also some benefit getting rid of 32-bit systems in the future. On the other hand, I see some benefit moving towards Java21 way before EOL on Java17. For example, virtual threads could improve our resource consumption. I always assumed we have a huge user base still using older RPIs. I remember a lot of discussions about tuning openHABian for such machines. Give me some time, I will open an issue to discuss possible paths towards Java21. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[florian-h05]

On the other hand, I see some benefit moving towards Java21 way before EOL on Java17. For example, virtual threads could improve our resource consumption.

True, but I am not sure if we do that because this would mean a new major and I think we avoid needing a new major release as long as possible.

what's wrong with providing a 32bit Java why does that increase support needs?(well for me in openHABian it does, but why in programming?)

External dependencies (like GraalJS for example) may abandon or already abandonded 32-bit support in current releases ... the only thing we can do is to not upgrade these dependencies and keep them on old versions that run on 32-bit.
This IS a security issue as we cannot upgrade if there are vulnerabilities found!

Do you want to abandon HW support for those?

At some point, yes. If we make the switch at or after mid of 2026, we recommended RPi 4 for at least 3 years and it is already available for 7 years. If you at that point still run old ARM hardware that does not support 64-bit, you have two options: Stay on your current openHAB version or upgrade to newer hardware. A RPi 4 2 GB costs aroung 50€, I think it should be possible to spent that money after years of no cost for openHAB server hardware.

Just take MS Windows 11 as an example: Microsoft abandonded support for I think millions of devices by requiring TPM (2.0) and other hardware requirements, whereas in several cases these devices would for sure be able to run Windows 11.

[ecdye]

I tend to agree with @florian-h05 I think if we are targeting EOL 2026 for 32 bit, we are giving plenty of time and there is plenty of reasons to upgrade by that point. I think if we hash out a rough roadmap now, and make clear and public the plan now it would be fine to target a final support date for 32bit

[holgerfriedrich]

Thanks for all the comments, please let us continue the discussion in openhab/openhab-distro#1689.