They are using GraalVM. GraalVM is able to fully compile java bytecode ahead of time (AOT), so they basically start x86 binaries. Of course that leads to very good start up times. But I have read that GraalVM does not work well with OSGi which is used by openHAB.
And by speaking of OSGi. That existed way before Java9 jigsaw aka modules. So openHAB by itself is very modular actually. And it is a simple compile switch that converts an OSGi bundle into a java9 module (almost).
OSGi is a runtime modular system though. The advantage is that any binding can be thrown in at any time and the system will adapt. So we cannot simply link a static runtime and have a smaller memory footprint, because the next user will require exactly the method that you have removed. But openHAB already requires that you only use methods from the Compact Profile 2.
Well, my concern when it comes to home automation is not that much “speed” but security and trust. So to what extent does this VM provide something to my OpenHAB installation? Nothing as far as I can see. It’s surely relevant in some other domains.
Just my 2ct.
By the way, what about the next release of Java? 12, 13, 14, …
openHAB is not using any deprecated JDK methods, so new versions should be fine. Java 8->9 was actually the big challenge with the module system, but it currently looks like OH 2.5 will be java 11 compatible.
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)…
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.
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/…
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.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
36
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.
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.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
40
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.
) , and openHAB wouldn’t really benefit from going to 64. If you see a use case please prove me wrong.