OpenHAB 3.4.3-1 & Java-17 Warning

Hi there - Just upgraded my installation to 3.4.3-1, and whilst it appears to work ok, I got an warning stating that Java-17 was required.

Get:1 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable/main amd64 openhab all 3.4.3-1 [104 MB]
Fetched 104 MB in 2min 42s (642 kB/s)                                                                                                                                          
(Reading database ... 156146 files and directories currently installed.)
Preparing to unpack .../openhab_3.4.3-1_all.deb ...
Unpacking openhab (3.4.3-1) over (3.4.2-1) ...
Setting up openhab (3.4.3-1) ...

[openHAB] WARNING: We were unable to detect Java 17 on your system. This is needed before openHAB can be started.
[openHAB] Please install the current version of Java 17 or check the openHAB documentation for details.

Happy to upgrade to Java-17 if that is now recommended for OH3.4.x, but thought I better check first given the docs still seem to have Java-11 recommended for this OH versionā€¦ I thought that the Java-17 requirement was coming with OH4.0?

Cheers - Glen

That seems like a mistake, only Java 11 should be required. FYI @Kai

Got the same message. After upgrade to Java 17, Openhab 3.4.3. works fine with Java 17, except some JS transforms needs to be replaced by SCRIPT transforms, and scripts rules need update to ECMAScript-2021. Anyway, I was surprised this update to Java17 was not mentioned in the release notes. I had the inpression that OpenHaB did not start with Java 11, so I switched immediately to Java 17. I ran regularly sudo apt upgrade on Ubuntu, so updates for openhab are installed with little notice

@Kai, can you remove the release until this has been investigated? Cc @maintainers

I think the Linux packages should have been build using the 3.x branch and not main because that has:

Will 3.4.3 work with Java17?
I changed openHABian to use Java 17 on new installs before OH4 to collect experiences.
Squeezing both into one upgrade could result in massive issues, making it two steps will ease pressure somewhat.
Itā€™s in main branch (the ā€˜milestoneā€™ equivalent of OH) and Iā€™m thinking to forward it to the openHAB3 branch (the ā€˜releaseā€™ branch equivalent). Also wonder if we can keep it called like that and what else we would need to prepare in openHABian to get ready for prime OH4 time.

OOTB there will be issues with using Javascript for scripting and JS Transformation, because Nashorn is not available. This can be solved by installing an add-on from the marketplace, but is at least unexpected. Iā€™m not sure if there are other limitations.

Iā€™ve created a new ā€œpatchā€ build plan now that runs off the 3.x branch instead - and have built and published a new linux package with it. I hope that allows again the use of Java 11.

3 Likes

Cheers @Kai - That solved the problem. In the end, just a mis-placed warning, and OH 3.4.3-1 worked fine, but have tried installing 3.4.3-2, and it went through cleanly without any warningsā€¦

Get:1 http://nz.archive.ubuntu.com/ubuntu jammy-updates/main amd64 python3-tz all 2022.1-1ubuntu0.22.04.1 [30.7 kB]
Get:2 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable/main amd64 openhab all 3.4.3-2 [104 MB]
Fetched 104 MB in 52s (1,998 kB/s)
(Reading database ... 156146 files and directories currently installed.)
Preparing to unpack .../openhab_3.4.3-2_all.deb ...
Unpacking openhab (3.4.3-2) over (3.4.3-1) ...
Preparing to unpack .../python3-tz_2022.1-1ubuntu0.22.04.1_all.deb ...
Unpacking python3-tz (2022.1-1ubuntu0.22.04.1) over (2022.1-1ubuntu0.22.04.0) ...
Setting up openhab (3.4.3-2) ...

Setting up python3-tz (2022.1-1ubuntu0.22.04.1) ...
Scanning processes...
Scanning processor microcode...
Scanning linux images...

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

I might take @mstormi suggestion above, and upgrade to Java-17 anyway, ahead of OH4.0 - I donā€™t use JS transformations, and I made the direct leap of refactoring all my Rules-DSL into ECMA2021 when moving to OH3, so happy to be a guinea-pig for testing this,

Cheers - Glen

3 Likes

After update to OpenHAB 3.4.3-2 the sonos binding doesnā€™t working - HANDLER_MISSING_ERROR
After cache clean the sonos binding works.

Short answerā€¦ NO!!! or at least not that easy :slight_smile:

where openHAB itself seems to run, but bindings and scripts get messed up.

Modbus binding doesnā€™t work, because it gets back a null pointer exception on trying to call some transform script

2023-04-21 19:03:00.768 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found fo>
2023-04-21 19:03:00.961 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Execution of scheduled (1000ms) poll task BasicPollTask [getEndpoint=Mod>
java.lang.NullPointerException: Cannot invoke "javax.script.Compilable.compile(java.io.Reader)" because "engine" is null
        at org.openhab.transform.javascript.internal.JavaScriptEngineManager.getCompiledScriptByFilename(JavaScriptEngineManager.java:77) ~[?:?]
        at org.openhab.transform.javascript.internal.JavaScriptTransformationService.transform(JavaScriptTransformationService.java:119) ~[?:?]
        at org.openhab.binding.modbus.internal.SingleValueTransformation.transform(SingleValueTransformation.java:140) ~[?:?]
        at org.openhab.binding.modbus.internal.CascadedValueTransformationImpl.transform(CascadedValueTransformationImpl.java:51) ~[?:?]
        at org.openhab.binding.modbus.internal.ValueTransformation.transformState(ValueTransformation.java:48) ~[?:?]
        at org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler.lambda$16(ModbusDataThingHandler.java:1001) ~[?:?]
        at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707) ~[?:?]
        at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) ~[?:?]
        at org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler.processUpdatedValue(ModbusDataThingHandler.java:969) ~[?:?]
        at org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler.onRegisters(ModbusDataThingHandler.java:847) ~[?:?]
        at org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler.lambda$11(ModbusDataThingHandler.java:801) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
        at org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler.onReadResult(ModbusDataThingHandler.java:801) ~[?:?]
        at org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator.lambda$2(ModbusPollerThingHandler.java:144) ~[?:?]
        at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:807) ~[?:?]
        at org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator.notifyChildren(ModbusPollerThingHandler.java:142) ~[>
        at org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator.handleResult(ModbusPollerThingHandler.java:88) ~[?:?]
        at org.openhab.binding.modbus.handler.ModbusPollerThingHandler$ReadCallbackDelegator.handle(ModbusPollerThingHandler.java:105) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusLibraryWrapper.invokeCallbackWithResponse(ModbusLibraryWrapper.java:333) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusManagerImpl$PollOperation.lambda$1(ModbusManagerImpl.java:216) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.SimpleStopWatch.timeRunnable(SimpleStopWatch.java:152) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusManagerImpl$PollOperation.accept(ModbusManagerImpl.java:216) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusManagerImpl$PollOperation.accept(ModbusManagerImpl.java:1) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusManagerImpl.executeOperation(ModbusManagerImpl.java:614) ~[?:?]
        at org.openhab.core.io.transport.modbus.internal.ModbusManagerImpl$ModbusCommunicationInterfaceImpl.lambda$1(ModbusManagerImpl.java:812) >
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]
2023-04-21 19:03:01.001 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Execution of scheduled (1000ms) poll task BasicPollTask [getEndpoint=Mod>
java.lang.NullPointerException: Cannot invoke "javax.script.Compilable.compile(java.io.Reader)" because "engine" is null
        at org.openhab.transform.javascript.internal.JavaScriptEngineManager.getCompiledScriptByFilename(JavaScriptEngineManager.java:77) ~[?:?]
        at org.openhab.transform.javascript.internal.JavaScriptTransformationService.transform(JavaScriptTransformationService.java:119) ~[?:?]
        at org.openhab.core.transform.TransformationHelper.transform(TransformationHelper.java:125) ~[?:?]
        at org.openhab.transform.javascript.internal.profiles.JavaScriptTransformationProfile.transformState(JavaScriptTransformationProfile.java>
        at org.openhab.transform.javascript.internal.profiles.JavaScriptTransformationProfile.onStateUpdateFromHandler(JavaScriptTransformationPr>

And hmm, yes after reinstalling Java 11 with the config tool everything working fine again.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.