search

openhab / openhab-distro

The binary distribution of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.3k stars 391 forks source link

Add support for running openHAB with Java 17 #1316

Closed wborn closed 1 year ago

wborn commented 3 years ago

Java 17 was released on September 14th. This is a LTS release, so we should also support using it with openHAB.

This issue keeps track of what still needs to be fixed or investigated:

openhab-bot commented 3 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-and-future-jdk-versions-when/65572/43

wborn commented 3 years ago

The runtime seems to start with Java 17 :slightly_smiling_face:, but as expected DSL rules don't work:

[ERROR] [re.automation.internal.RuleEngineImpl] - Failed to execute rule ‘demo-8' with status 'UNINITIALIZED'

It's probably due to this exception:

[DEBUG] [.access.reflect.ReflectionTypeFactory] - class org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory cannot access interface jdk.internal.util.random.RandomSupport$RandomGeneratorProperties (in module java.base) because module java.base does not export jdk.internal.util.random to unnamed module @1d03e645
java.lang.IllegalAccessException: class org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory cannot access interface jdk.internal.util.random.RandomSupport$RandomGeneratorProperties (in module java.base) because module java.base does not export jdk.internal.util.random to unnamed module @1d03e645
    at jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) ~[?:?]
    at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:560) ~[?:?]
    at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory.createAnnotationReference(ReflectionTypeFactory.java:204) ~[bundleFile:?]
    at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory.createAnnotationValues(ReflectionTypeFactory.java:190) ~[bundleFile:?]
    at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory.createType(ReflectionTypeFactory.java:164) ~[bundleFile:?]
    at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeFactory.createType(ReflectionTypeFactory.java:84) ~[bundleFile:?]
    at org.eclipse.xtext.common.types.access.impl.ClassMirror.initialize(ClassMirror.java:55) ~[bundleFile:?]

As a result "Rule DSL" also doesn't show as an option when adding rules via the UI.

Because Nashorn was removed in Java 15, ECMAScript also doesn't show. It might still be possible to create an Automation add-on using nashorn-core for backwards compatibility and if GraalVM is not available for your architecture, see also: https://github.com/openjdk/nashorn .

J-N-K commented 2 years ago

Regarding XStream: I'm not too confident we'll see a Java 17 implementation anytime soon (in contrast to XText where at least a roadmap exists). Maybe a change to Jakarta XML Binding 3 should be considered. There are already some addons using JAXB 2.x (while some others use XStream), so this could be unified, too.

Flole998 commented 2 years ago

@wborn Seems like Azul has published an armhf version now, so I think you can mark that as completed.

wborn commented 2 years ago

Regarding XStream: I'm not too confident we'll see a Java 17 implementation anytime soon (in contrast to XText where at least a roadmap exists).

I haven't seen any XStream issues so far with my distro builds on Java 17. Only when running unit tests there were some:

com.thoughtworks.xstream.converters.ConversionException: 
No converter available
---- Debugging information ----
message             : No converter available
type                : java.util.Collections$UnmodifiableRandomAccessList
converter           : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
message[1]          : Unable to make field private static final long java.util.Collections$UnmodifiableCollection.serialVersionUID accessible: module java.base does not "opens java.util" to unnamed module @5b6fe39e
-------------------------------
    at org.openhab.core.config.xml.util.XmlDocumentReaderTest.defaultSecurityAllowsDeserializingOHCobjects(XmlDocumentReaderTest.java:70)

It looks like the add-opens workaround most issues. So I've also added them to fix similar issues for the unit tests in https://github.com/openhab/openhab-core/pull/2788.

I also saw similar issues with Gson deserialization in tests. Upgrading to Gson 2.9.0 fixed the issues I ran into (Fix failing to serialize Collection or Map with inaccessible constructor), as well as the add-opens workaround.

wborn commented 2 years ago

There are also some new annoying warnings we might want to look into. :roll_eyes:

You'll see this on startup:

WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.eclipse.osgi.internal.framework.SystemBundleActivator (file:runtime/system/org/eclipse/platform/org.eclipse.osgi/3.16.300/org.eclipse.osgi-3.16.300.jar)
WARNING: Please consider reporting this to the maintainers of org.eclipse.osgi.internal.framework.SystemBundleActivator
WARNING: System::setSecurityManager will be removed in a future release

Similar warnings are printed when SAT runs Spotbugs on Java 17. See: https://github.com/spotbugs/spotbugs/issues/1579

J-N-K commented 2 years ago

@wborn XStream: That's good to hear. I just read the issue you linked above and it seems to be an issue. Probably we don't have private final fields in objects we serialize/deserialize.

wborn commented 2 years ago

Because Nashorn was removed in Java 15, ECMAScript also doesn't show. It might still be possible to create an Automation add-on using nashorn-core for backwards compatibility and if GraalVM is not available for your architecture, see also: https://github.com/openjdk/nashorn .

I've created a JSScripting (Nashorn) add-on using the standalone Nashorn Engine which can be installed using the Marketplace.

J-N-K commented 2 years ago

That (together with https://github.com/openhab/openhab-core/pull/2883) and the next release of KARAF all issues seem to be resolved.

wborn commented 2 years ago

Yes your transformation PRs look very promising! 👍 I plan on testing them soon. 🙂 Do you know if multiple JS scripting engines are also supported by the script transformation/profile in case users are still migrating between engines?

J-N-K commented 2 years ago

Yes, it should, because they use different mime-types. The nashorn engine uses application/javascript and the Graal engine uses application/javascript;version=ECMAScript-2021, so depending on what is set as script-type, one of these will be selected.

openhab-bot commented 2 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/java-17/135948/2

openhab-bot commented 2 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/building-on-linux-vs-windows/136338/2

J-N-K commented 2 years ago

Regarding the Nashorn add-on: I think this should be added because otherwise a lot of code will need changing.

florian-h05 commented 2 years ago

Regarding Java 17, do you know if the automatic file reloading of the JS Scripting add-on is working?

I am asking, because yesterday someone opened an issue on openhab-js and had problems with files not loading on Java 17: https://github.com/openhab/openhab-js/issues/130.

J-N-K commented 2 years ago

The reason is that Nashorn is missing on Java 17:

The ScriptFileWatcher checks if an engine is available for the type js before it loads a file. The subclass JSScriptFileWatcher (watching automation/js) overloads the createAndLoad method, so after the super class found out that the script type is supported, it'll use the Graal Engine to process the script.

On Java 11 this works, because Nashorn is available. On Java 17 Nashorn is not available, so the script type js is not registered and the createAndLoad method is never called. I'll provide a fix for that.

openhab-bot commented 2 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/send-command-to-serial-port-and-receive-a-answer/138672/64

openhab-bot commented 1 year ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-0-snapshot-discussion/142322/22

wborn commented 1 year ago

Everything is done now! :partying_face:

openhab-bot commented 1 year ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-4-oh4-0-2/148900/20