Hazelcast indicates it needs additional modules

Using a clustered Openfire 4.8.3 environment with hazelcast, windows and java 17.
Currently this plugin is adding some logging in the stderr.log (and not in the openfire.log!! ) about missing modules

WARNING: Hazelcast is starting in a Java modular environment (Java 9 and newer) but without proper access to required Java packages. Use additional Java arguments to provide Hazelcast access to Java internal API. The internal API access is used to get the best performance results. Arguments to be used:
 --add-modules java.se --add-exports java.base/jdk.internal.ref=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.management/sun.management=ALL-UNNAMED --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED

And it is correct, in the logging there are exceptions indicating the same issue:


2024.08.07 14:24:55.288 TRACE [PluginMonitorTask-2]: com.hazelcast.internal.networking.nio.NioThread - [10.7.13.140]:5701 [openfire] [3.12.5] Failed to optimize Selector: sun.nio.ch.WEPollSelectorImpl
java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Set sun.nio.ch.SelectorImpl.selectedKeys accessible: module java.base does not “opens sun.nio.ch” to unnamed module @3991a81f

Also the hazelcast documentation confirms this:
https://docs.hazelcast.com/imdg/3.12/getting-started/running-in-modular-java

So I tried to remedy this by adding the proposed lines to the openfire-service.vmoptions but this had no effect at all. Other options in this file are picked up, but not these ones.

The cluster is working, so no real side effects yet, just a huge mystery for me.

We are now also running into this issue, when developing on other home brew Plugins, which contain some legacy 1.8 code. It looks like that code which is running form the Openfire Server threads is taking the additional Java arguments into account, but not the plugin specific threads. also the behaviour is not completely deterministic.

I would appreciate if somebody has some more insight in the threading model used to run Plugins. What is the intention and what are the side-effects?