The currently don’t support arm 32, bud I did put in a feature request for it Add support for Linux 32 and 64 bit arm · Issue #60 · corretto/corretto-8 · GitHub.
New java features are actually neat and help to get the language out of the 90s.
I don’t see a reason to stick to Java 8.
1 Like
Me not either. Nice to maybe receive new Java features. But it’s also up to the respective developer to adopt those. I mean, not even all “new” Java 8 features are used in the current framework (or even bindings)…
Java 8 is the last version of Java that works with 32 bit processors.
Are there any 32bit only platforms left? On x86 64bit brings more registers, more simd instructions, a wider memory bus. I do not see a reason to stick to 32bit. Do you?
Raspberry Pi (1,2,3) usually works in 32 bit mode. I guess this is the most common openHAB platform. AFAIK Raspbian (the base of openHABian) is only available as 32 bit.
2 Likes
There is a 64-bit version coming, but it will take some time to become a stable version of openHABian, I guess. We have to be patient.
Not to mention all the Raspberry Pi clones. Many of them are supported by Armbian (https://www.armbian.com/)
This 32 bit versus 64 bit discussion is getting very interesting.
- Oracle stopped supporting 32 bit platforms for pretty much anything newer than Java 9
- No more security update on Java 8 (at least from Oracle)
- Most (cheaper) ARM based platform are 32 bit
- OpenHAB supports primarily Java 8, but intends to support newer Java versions
This hints for me to:
- NOT to use OpenHAB on 32 bit platforms
- Continue with my current physical separation of bridges/gateways and controllers (OpenHAB)
- Find a solution those bindings behaving unreliable within such a separated setup
or
simply ditch this evil mess called “Oracle” and go for something completely different. Sure, there are alternative Java binaries provded like from https://adoptopenjdk.net/…
1 Like
For me, it is usually openJDK or Azul JDK. They work without any issues in both “native” ond dockerified installations…
1 Like
A RPi 3 already has a 64bit processor (it’s the most common HW to run OH on if you were to choose today).
But why would you want to have that? There’s no inherent relevant limit in 32 bit this will remove (remember noone needs more than 640KB 
) , and openHAB wouldn’t really benefit from going to 64. If you see a use case please prove me wrong.
It’s rather the opposite, same program and data in 64 bit will consume way more memory:
running on 64bit x86 takes about 4 times as much mem as on 32bit ARM.
That’s ok on a PC, but on a low-mem, not memory-expandable system like a RPi that is critical.
And Oracle JDK ain’t needed.
Zulu (Embedded) is absolutely fine (and thus the default in openHABian) and will continue to be available in 32 and 64 bit.
1 Like
And the current Raspbian is 32 bit only.
Sorry to bump an old thread, but it seems the logical place to put this question, as it follows the theme.
I have been using Odroid C4 devices with Arm64 chips, running DietPi V7 (Debian Buster) which loads openJDK11 quite happily and openHAB3.2 is working really well on it. (as well as some other software)
However, as part of asking Michal of DietPi to include openHAB in the dietpi-sopftware menu, he has asked if openHAB3 ONLY works on Java 11 or if it will run on Java 17, as that is what Debian Bulleye is moving to.
so my question is…
- Is openHAB3 limited to Java 11, or can it run on Java 17?
Either way, Michal will either let it roll on Java 17, or as part of the Dietpi-software script he will edit the /etc/default/openhab file and point to Java 11 (which well be installed in the same process as a dependency.
openHAB 3 is limited to Java 11, no higher versions supported.
1 Like
Thanks for the quick response.
I’ll let Michal know.
Apparently he has plans for adding support for JAVA versions per application anyway.
1 Like
I’ve just ran test against JDK 16 and openHAB 3.1 booted without any issues. I believe 17 will be the same. Most of stuff which is compiled against Java 11 will survive with 16 and 17. Issue is definitely other way around - if you try to run stuff compiled against Java 16 under 11.
Some dependencies might spot issues yet this should not affect core to much.
Hi
That’s curious.
I tried it with Java 17 (openJDK) on an Odroid C4 with DietPi 7 and Debian Bullseye, it just keep restarting every 2 seconds.
The screen dump is at the bottom of this thread
I installed both JDK 17 and 18 and indeed it does not boot. Yet issue is not caused by openhab itself but underlying components (Karaf/Equinox).
Looking closer at the issue - seems JDK 17 removed one of very common, yet not officially supported mechanism called sun.misc.Unsafe. This caused issues for many things, including Equinox and Felix (https://issues.apache.org/jira/browse/FELIX-6430). I’d say that you’re safe up to 16, getting on Java 17 will require some more dependency updates.
In order to get up to JDK 17 you have to wait for Karaf to update Felix/Equinox to latest versions. Only then it will be possible to run whole thing on this release.
5 Likes
Small update - Karaf 4.3.3, released this (13 September 2021) morning is compatible with JDK 17. I just had a test spin and it loads nicely with Java 17.
Below screenshot for JDK 16, results are the same for 17 
1 Like
openHAB now uses Karaf 4.3.3. 
There is probably a lot more to fix so I’ve created an issue for this:
2 Likes