Seems there is no newer SNAPSHOT of openHAB 3.0
I thought there would be already a newer version via apt as there are already some newer versions then S1919 here: https://openhab.jfrog.io/openhab/list/openhab-linuxpkg/pool/main/
And you won’t be able to access the administration area on home.myopenhab.org until https://github.com/openhab/openhab-webui/pull/328 is merged too, we worked on this yesterday, still some last issues to iron out but it shouldn’t be long now.
I came to notice your preference for (Oracle) OpenJDK. But most(?) users are probably using Azul Java. We don’t (actively) support OpenJDK in openHABian for a number of reasons such as licensing and performance, I therefore wonder why you recommend it here in the packages and your tutorial.
[13:48:29] root@devpi:/home/openhabian/openhabian# apt install openhab Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: openjdk-11-jdk | openjdk-11-jre
302 didnt work; still getting that www-authenticator error.
eagerly waiting for 307 and 328. Confirmed that administrator section results in 502 bad gateway but the cloud connection seems online per-se and google assistant is able to discover the devices.
If you are still on SNAPSHOT 1919, this fix is not included.
I thought there were licencing issues with Oracle Java SE, but not the distribution provided openJDK.
Nonetheless, I temporarily removed zulu from the suggested packages because I had trouble finding the package names that Zulu provides (or if the latest 11 for arm package is up to date). The
suggests field is a work in progress and I think you’re right that it is being too specific: It should probably be reduced to:
“default-jre | java11-runtime-headless | zulu11-jre”
1923 is installed now i confirmed that 302 is included in the jar file.
openhabian@openhab:~$ sudo apt list --installed | grep openhab openhab/unstable,now 3.0.0~S1923-1 all [installed]
Yeah Azul have changed their API that has been somewhat annoying for everybody to follow along.
But we did and have implemented that in openHABian so why bother ? I suggest installing openHABian and use it to install the JVM even if you don’t want to use the image or any of its other features.
We also provide Adopt OpenJDK 11 but no (Oracle) OpenJDK.
These are what we test drove, too.
I think so too but at least any company will want to use a supported Java hence choose Java SE or any of our alternatives. Sure companies is not our #1 target but no need to exclude them for no good reason either.
Suggesting on the forums or the docs that you use openHABian to manage is a good idea and probably the easiest option but
openhab-linuxpkg is setup to try to be as compatible with any OS with a .deb (or .rpm) package manager and although unlikely that may mean that someone can’t or doesn’t want to install openHABian. I add it as a suggestion as an
apt compliant way to imply that you may need to install an additional package.
default-jre | java11-runtime-headless covers most Java package installs, including Adopt OpenJDK but I don’t think it covers Zulu’s packages, I’ll find (if it’s different to
zulu11-jre) and add it when I can.
java11-runtime so it should be okay:
Package: zulu-11 Status: install ok installed Priority: extra Section: java Installed-Size: 323608 Maintainer: Azul Systems, Inc. <email@example.com> Architecture: amd64 Source: zulu-11 Version: 11.41+23-1 Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime, java9-runtime, java10-runtime, java11-runtime, java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk, java8-sdk, java9-sdk, java10-sdk, java11-sdk, java7-jdk, java8-jdk, java9-jdk, java10-jdk, java11-jdk Depends: java-common, libasound2, libc6, libgcc1, libx11-6, libxau6, libxcb1, libxdmcp6, libxext6, libxi6, libxrender1, libxtst6, zlib1g, libfontconfig1 Description: Azul Systems Zulu JDK 11.41+23 (11.0.8-b10) Azul Zulu is an enterprise-quality, commercialized distribution of OpenJDK that can be deployed across various operating systems, Docker containers, hypervisors and Cloud platforms. Zulu is a compliant implementation of the Java SE specification, verified with the OpenJDK Community Technology Compatibility Kit. Zulu distributions are available for a variety of Linux operating systems with appropriate TGZ, APK, RPM, and Debian package types, including Linux repository access via yum, apk, and apt-get. To see all Zulu details, review user documentation, and check for downloads, visit https://www.azul.com/zulu.
Perfect, thanks @ysc!
The performance issue with OpenJDK on Raspberry Pi’s was because it used softfp instead of hardfp.
I.e. floating point calculations were done in software instead of using the dedicated hardware in the CPU.
That obviously impacts performance. If it uses softfp or hardfp depends on the compiler options used for compiling OpenJDK.
Probably softfp was used because it was the easiest way to make Raspbian compatible with all Raspberry Pi models and because hardfp is not supported by all 32-bit ARM chips. See also The Difference Between HardFP and SoftFP.
All ARMv8 chips support hardware floating point so when a 64-bit OS is used on an ARM chip there won’t be any such issues because there are no softfp/hardfp compiler options for that architecture.
I haven’t checked the performance of the openjdk package on the 32-bit Raspbian OS recently, so I don’t know if this is still an issue.
Also note that Zulu has SF builds which will have the same performance issues.
So it all depends on the architecture and compiler options used for building OpenJDK.
They do but we take care to use the HF ones.
Good to know, thank you! Does the following show raspbian’s default openJDK correctly uses hard-float?
pi@server:~ java --version openjdk 11.0.8 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Raspbian-1deb10u1) OpenJDK Server VM (build 11.0.8+10-post-Raspbian-1deb10u1, mixed mode) pi@server:~ $ readelf -h $(realpath /usr/bin/java) ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x1085c Start of program headers: 52 (bytes into file) Start of section headers: 4460 (bytes into file) Flags: 0x5000400, Version5 EABI, hard-float ABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 28 Section header string table index: 27
I checked openJDK 8 on the latest raspbian release which shows the same ABI flags however.
I checked the result with the Zulu SF/HF builds and the result is as expected.
$ readelf -h zulu11.41.75-ca-jdk11.0.8-linux_aarch32sf/bin/java | grep Flags Flags: 0x5000202, Version5 EABI, soft-float ABI, <unknown> $ readelf -h zulu11.41.75-ca-jdk11.0.8-linux_aarch32hf/bin/java | grep Flags Flags: 0x5000402, Version5 EABI, hard-float ABI, <unknown>
Excellent, that’s looking promising for using default-jre/openJDK again!
From what I can remember, the problem was particularly noticeable when openHAB was trying to create an SSH key for the first time. I’ll source an Pi 2 from somewhere and give it a go.
That would indeed prevent some issues.
I remember running into it on my RPi 3B with the Raspbian Jessie builds.
Hello @ysc , i am tracking this closely. I beleive #328 is merged and i suppose build #1927 of the linuxpkg includes this (or am i wrong? sorry i am still learning).
I still cant access the admin page from home.myopenhap.org. results in 502 bad gateway.