Seems there is no newer SNAPSHOT of openHAB 3.0
2 Likes
Ahh ok.
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/
1 Like
And you won’t be able to access the administration area on home.myopenhab.org until [Main UI] Pass access token in header if cookie flag set by ghys · Pull Request #328 · openhab/openhab-webui · GitHub is merged too, we worked on this yesterday, still some last issues to iron out but it shouldn’t be long now.
5 Likes
Hi @benjy,
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
1 Like
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.
Are the performance issues of openJDK still prevalent in JDK 11 for ARM devices? (@Kai, @wborn would you know?)
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.
Agreed, 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.
1 Like
The latest zulu11.41.23-ca-jdk11.0.8-linux_amd64.deb provides 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. <azul_openjdk@azulsystems.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.
2 Likes
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.
2 Likes
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.
thanks
@candiesdoodle I believe the openhab-cloud fix (https://github.com/openhab/openhab-cloud/pull/307) hasn’t been deployed in production yet (@digitaldan?).
But I’ve confirmed on a dev instance that it works.
2 Likes