Roadmap for Java21 and ending support for 32-bit systems #1689
Comments
|
My personal opinion:
|
|
Thanks @holgerfriedrich for opening this up. I think having a well defined EOL for 32 bit systems with ample time for users to make the switch sounds like a solid approach. I agree that having to support 32 bit systems in the future is going to slow us down, even with a 32bit JDK21 for PI's. As others have pointed out, many libraries with native bits will have or already have dropped 32 bit builds (like GraalVM). Besides threads, i am also looking forward to pattern matching in switch statements and string literals...... its been a long time coming. |
Restrictions of dependencies
|
|
I fully support this. When we follow the regular update cycle, there are three options. Summer 2025, Christmas 2025 or summer 2026. Would a 32bit java21 look like a real solution or would it be crippled? Either way I think it is better to cut the cords and move on as rpi hardware is not that expensive and it’s successor is already available for 5-6 years when this release comes out. |
|
Christmas 2025 might be a good choice, because people can then put a lot of RasPi 5 under their christmas trees. 🎄 🎄 🎄 |
|
A heads-up one year in advance should give everyone plenty of time to prepare for it. The question I have is will we then also fully drop 32-bit ARM support? That would mean also actively removing 32-bit ARM libraries and Docker images etc. |
If we want to upgrade dependencies that no longer supports 32 bit, I guess this would be needed? |
IMO: yes. Something that might not work should either be fixed or removed, otherwise people will start "openHAB works only sometimes". We should avoid that. |
|
@holgerfriedrich Thanks for starting this discussion!
IMO yes — even though most parts of openHAB would very likely continue to work if only upgrading the libraries mentioned above, I can already see all the posts „add-on xy not working“ on the forum. And given the increase in resource consumption from Java 11 to Java 17 I think it should again increase from Java 17 to Java 21. This could start causing really bad performance on 32-bit Arm, I would rather have our users buy a new RPi4 2GB for roughly 50€ after they used their old Pi for years, than have unhappy users die to bad performance. |
|
Fully removing ARM 32-bit support would also make the most sense to me instead of ending up with some untested and degraded user experience. 👍 |
|
I am not as enthusiast as you are with the removing of old 32-bit RPI support. Old 32-bit RPI could still be what is the most used by openHAB users (we could start a survey on the community forum to have a more precise proportion of impacted users). This means they will have to buy a new hardware and install & setup everything from scratch. Not something obvious for everybody and time consuming. Do we know if our big challenger is still supporting 32-bit RPI ? If yes, users may be tempted to keep their old hardware and switch to another solution ? PS: of course, I will buy a PI 5 myself ;) |
Their latest Home Assistant OS release still has images for 32-bit Pis (see https://github.com/home-assistant/operating-system/releases/tag/13.1), but their docs only provide links to 64-bit HAOS for Pi 3, 4 and 5 (see https://www.home-assistant.io/installation/raspberrypi#downloading-the-home-assistant-image).
So it seems like they still provide HAOS for 32-bit Pis, but they do not mention that in their docs and require you a Pi 4 or Pi 5 (Pi 3 is "okay to get started" only). I therefore doubt users will keep their old 32-bit Hardware and switch to Home Assistant, where the docs don't even loose a word about their old 32-bit hardware ... and given the HAOS is heavily relying on Docker to provide it's additional services and many Docker images already removed 32-bit ARM support, I think the experience with HAOS on 32-bit ARM isn't that great ... |
I finally in the beginning of this year upgraded from RPi 3 (32 bit) to 5 (64 bit), and it runs so fast and smooth now - especially startup time and loading/running JavaScript rules. Even though 32 bit is still fully supported, RPi 3 (or even lower) doesn't provide a good user experience anymore IMHO.
The more hardware we could support, the better, and I also hate to turn still working hardware into trash. But it's not only about what would be nice - we have to adapt to the world around us as a small part of a bigger ecosystem moving away from 32 bit. Already in 2018 I had to replace by fit-PC2i with a Fitlet2 for my Linux server, since CentOS had dropped 32 bit support. That was inconvenient for me and kind of a waste, but I fully understand the decision. It's costly, sometimes impossible, trying to keep up with security upgrades etc. when dependencies have moved on.
You won't regret that. 😄
I'm wondering if it would be possible add information to I guess only very few users are still on 32 bit and using Derby (for example). GraalVM is probably a harder case, and maybe it's not worth even considering for this reason? |
For those that don’t want to move away from 32-bit one could compile a JS Scripting add-on version that runs on 32-bit for openHAB 5, it would however won’t be developed anymore … And as you shared your experience with Pi 3 to Pi 5 upgrade: Its absolutely worth to upgrade, not only to use 64 bit! |
|
Openly speaking, I would like to see Java21 way before 2026! Maybe it is easier to understand for the end user if we introduce both Java21 and end of 32-bit support together in the first OH5 release. Target date Christmas 2025 for Java21 would basically mean that we switch to Java21 in core development mid next year, dropping all Java17 builds and start using Java21 features. Add-on development would probably still stick to Java17 feature set for at least until the release after. There are still add-ons which are also compiled for older OH releases. I remember the discussions when I started to introduce Java17 features over the whole add-on repo - deliberately done more than 6 months and one release after core had switched to Java17 features. I would like to hear about your concerns and understand why we should shift this so much towards EOL of Java17.... |
Me too. However, this:
would be some kind of middle ground (not rushing, not too conservative) allowing us to start developing with Java 21 after 4.4 in the summer next year. If we can decouple the transition to Java 17 from the transition away from 32 bit, we might be able to switch to Java 21 one release faster, i.e. summer 2025 with development cycle 5.0 starting in Christmas this year after releasing 4.3? One advantage would be that (from my personal observations) maintainers and contributors seem to have more time for openHAB development during wintertime (especially Christmas) than during summertime. Then summer release 2025 would be 5.0. The only "big thing" I'm aware of right now being in development or planned is the Matter implementation. This would be nice to provide as part of a major new version, so 5.0 won't just be another forced Java upgrade without any big user-oriented improvements, making users really wanting to upgrade. I don't know if this is realistic, @digitaldan? For users, Christmas is probably a good time for hardware upgrades and reinstallling a major new version of openHAB, but from a development perspective Christmas is kind of a good time for doing the first steps towards a next major release. So this might be somewhat conflicting. Just some thoughts and wishful thinking... 😄 |
|
@holgerfriedrich maybe a list of things that have to be done can give some guidance to the timeline. If i understand your post correctly, you would prefer to have a release in summer 2025, meaning OH5 will start development this Christmas. (7 weeks from now). To me that feels somewhat as a rush, buit i don't have full insights to all the things that need to be done. I would strongly advice to couple both java21 and removal of 32 bit support into OH5. As these are mayor breaking changes clear communcation is more important then extending the - already subpar - experience on a rpi3 for 6 months. Also don't forget that tehir openHAB will not stop working on the day of OH5 release. Just my 2 cents. |
While I think this is a good idea, we then should also tackle openhab/openhab-core#4062. Otherwise all marketplace addons will have again to be compiled specifically for an older version, and we get complaints again. If the issue is tackled now for 4.3, we could introduce an extra field in 4.4. |
I will note that I for one had a openHAB instance up and running in my parents house for upwards of 2 years without ever touching it to upgrade the base openHAB version because of other reasons. It was solid as a rock and I only had to help them remotely restart it maybe twice during that time. I say this to point out that ultimately if the end user wanted to keep going with their 32 bit machine, they probably could continue right where they were at for a while longer before upgrading. |
|
Hi guys, I am not here to comment as a developer but would like to share m point of view as "customer".
Many thanks for all your great support, effort and enthusiasm to keep this great project alive! I personally consider purchasing another PI5 and move! At the end: it is all about fun! Kind regards, |
|
If today I run Pi OS 64 bit on a PI 5, can I install our current official openHAB distributions without any degradation ? |
This is what I am running on my development setup. I tend to say "yes". |
|
I totally agree that openHAB 5, 32-bit EOL and Java 21 should be coupled together, even though that means we won‘t be able to use Java 21 features before openHAB 5. If we plan openHAB 5 for Christmas 2025 (which IMO would be a good schedule), core could start using Java 21 features summer 2025 and users would know that we will drop support for 32-bit one year in advance. And as @ecdye pointed out, you can still continue to run your current Ultimately, we should couple openHAB 5 with Matter support to provide something to the users and not only make it 5.0 for the developers experience.
Didn‘t know RRD is hardware dependent, we should figure out a way to migrate that.
Unfortunately this is out of scope for us openHAB devs to manage other software. |
The binding is not in bad shape now and supports a lot of device types. I'm living with it in my production system with about 20 devices and am pretty happy. The only thing stopping me from doing an official beta is i want to make sure i lock down the general thing and channel structure from changing , right now i have the freedom to make sweeping changes and not affect too many people. I also am thinking about breaking out the runtime as its own addon (something like This is a long way to say, December 2024 might be tough for an official release, but i will definitely have a beta, possibly in the marketplace for users to test with. But summer 2025 would likely be when openHAB officially ships with it. |
|
Great to hear your progress!
Then that’s a good reason to release openHAB 5 in summer I think. Someone above also said that it seems our devs have more time during winter, so from dev perspective it would make sense as well. |
|
+1 for summer release. Slightly off-topic: are we ready to remove the band-aid for other parts like DSL Rules, or are there other parts that we should 'clean-up' ? |
|
IIRC @J-N-K was thinking about refactoring rules DSL to an add-on for openHAB 4. I don’t know the background behind this idea, maybe Jan can tell us more about it. |
|
@kaikreuzer How should we make an „official“ decision here so we can announce it when releasing 4.3? |
|
The discussion found its way to have openHAB 5 next summer. I would say, if nobody from @openhab/maintainers vetos against this in the coming days (let's say by next weekend), we can consider this a joint decision. |
FYI: RRD is hardware dependent, RRD4J is not. We use RRD4J, so we don't run into an issue here. |
|
I wanted to switch from RPI3b to RPI4, both 32bit but failed. The reason is that the WLAN module in RPI4 is worse than in RPI3. I compiled the newset version of wpa_supplicant, switched from 60 to 50 Hz, reduced the resolution as there is interference between WLAN and HDMI. No matter what I tried, and I tried a lot, the WLAN module of RPI4 is not as reliable as in RPI3. In RPI4, when it is far away from the router, sometimes it connects, sometimes it does not, while RPI3 always connects from the same place. So at the end I returned to RPI3b. Why running 64bit Java on RPI3 is not an option, does it need too much RAM? In any case, to speed up the whole thing I moved from JS Scripting to Groovy, as I think the latter requires less RAM (has smaller jar file anyway). For reducing the RAM needed by OH there is a different ticket, but I think OpenAPI, Language Server, voice, model.ide.* (or alike) should be converted to add ons. These might be initially installed, but the user should have the possibility to uninstall them from the Market place (not to stop them in Karaf -utterly complicated to find out what can I stop, what I do not need, without breaking what I need, after upgrade Karaf forgets which bundles were stopped). Ultimately a scripting language, which has very low runtime memory overhead (XTend, but not in it current form as DSL; or Java as JSR223 langauge) can keep OH fully functinal on low memory 64bit devices. So if less RAM is required by OH in 64bit mode, it can still run on RPI3. If all addons I use (I do not user GraalVM) continue running on 32bit, I will stay on 32bit. That said, I see no problem if some addons run only on 64bit and some on both 32 and 64 bit, as long as this is documented. How is Matter support related to Java 21 or 64 bit? Is the intended release date by coincidence just the same, or there are more dependencies? |
Matter currently works with Java 17 32 bit so this is fully unrelated. |
It is no option to officially say that this is a supported environment.
I am not sure how large the effects of this are, but anyway those refactorings would be a larger effort.
Will that documentation be read by all users? I doubt that, given how often problems arise during updates because users did not check the breaking changes section of the release notes before updating. |
It's not. The reason is you tried manually instead of using openHABian, we have lots of people including myself (maintainer of that stuff) running on RPi4/32bit. Don't confuse 32/64bit in hardware and openHABian (the OS) with openHAB and Java (which is what this issue and discussion is all about).
Exactly. Because we as maintainers cannot provide the level of support it would take to test and ever-validate all those possible combinations.
Oh dear. I see you have not been a maintainer confronted with people not reading docs but expecting stuff to nonetheless work out of the box. |
This is a summary of the current state:
Default Java version for openHAB 4.x is Java17.
Though, we already support compiling and running openHAB with Java 21.
New features of Java versions >17 cannot be used, until we reach the point where we want to end support for Java17.
Java17 will reach EOL in Sep 2026. This is the latest possible date we should have completed the transition to Java21 (and as I understand our versioning so far, this should be along with a new major version 5.x of openHAB).
Java21 is typically only available for 64-bit systems, and this ties the decision when to switch to Java21 also to a decision when to give up the 32-bit platform. For us, this is complicating the switch form Java17 to Java21, as we seem to have a big community out there using older Raspberry PIs, RPI3 or even older with limited amount of memory.
Now there is at least one Java21 JRE available for 32-bit ARM (and available through openHABian openhab/openhabian#1902).
This could allow us to switch to Java21 without/before discontinuation of 32-bit systems.
Discussion of further options:
As we already seen in
openhab/openhabian#1902 (comment) and following, there might be technical reasons for introducing Java21 early before EOL of Java17, and there might also be technical reasons to drop 32-bit systems.
I would like to hear the opinion @openhab/maintainers about both Java21 transition and about dropping support for 32-bit systems.
The text was updated successfully, but these errors were encountered: