WildFly 41 fails to start on Java 25: missing default modular JVM options (--add-opens/--add-exports)

Aperta
  • Qualcosa non va?
#766 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@claudioweiler ci sta già lavorando.

Dal 12/10/2026.

  • #767 di @claudioweiler — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
java
Ambito
devtools

Direzione di ricerca

The issue identifies RSP's internal JVM launch argument assembly and WildFly's bin/common.sh setDefaultModularJvmOptions as the relevant entry points. Compare the JVM arguments RSP builds with the 16 flags listed in the issue, then check how the launch behaves on a modular JDK. Done means the required flags reach WildFly when launched through RSP and the Java 25 startup failure is resolved.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Hi all!

Summary

When starting a WildFly 41 server on Java SE 25 through RSP, the server fails to boot because RSP builds the JVM command line directly and does not inject the default modular options (--add-opens and --add-exports) that WildFly defines in bin/common.sh. Under Java 25, these flags are mandatory for WildFly's startup sequence, causing startup to crash with IllegalAccessException.

Environment

  • RSP server type: org.jboss.ide.eclipse.as.wildfly.380 (used as the latest available server adapter, as a dedicated wildfly.410 type is not yet defined)
  • WildFly: 41.0.1.Final (embeds wildfly-core 33.0.1.Final)
  • JDK: OpenJDK 25 (25.0.4.1)

WildFly 41 lists Java SE 25 as a recommended JDK for Jakarta EE 11: https://www.wildfly.org/news/2026/07/16/WildFly-41-is-released/

What happens

The server fails during startup with:

java.lang.IllegalAccessException: module java.base does not open java.util to unnamed module
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn
	at org.wildfly.clustering.marshalling.protostream.util.Reflect.getVarHandle
	at org.wildfly.clustering.marshalling.protostream.util.EnumMapMarshaller.<clinit>

The logged VM Arguments contain no --add-opens or --add-exports entries, and the launch command invokes org.jboss.modules.Main directly rather than executing standalone.sh.

Root cause

RSP launches WildFly by invoking org.jboss.modules.Main directly, bypassing the standard startup scripts (standalone.sh → common.sh). WildFly's common.sh (setDefaultModularJvmOptions) normally injects the required module-access flags on modular JDKs. Because RSP assembles the launch arguments internally and omits these flags, none of them reach the JVM.

Although strong encapsulation has been enforced since Java 17 (JEP 403), WildFly 41 / wildfly-core 33 components (such as org.wildfly.clustering.marshalling.protostream.util.EnumMapMarshaller) now perform reflective package access via MethodHandles.privateLookupIn on java.util.EnumMap early in the boot sequence. Under modern modular runtimes such as Java 25, this strictly fails unless --add-opens=java.base/java.util=ALL-UNNAMED is supplied.

WildFly 41 declares 16 flags in bin/common.sh (wildfly-core 33.0.1.Final): 5 --add-exports and 11 --add-opens, including the required flag for java.base/java.util.

Expected behavior

When launching WildFly on modular JDKs (or when a newer WildFly server adapter is added), RSP should apply the default module-access flags matching WildFly's common.sh, enabling the server to boot on Java 25 out of the box without requiring manual user intervention.

Workaround

Manually add the modular access flags to the server configuration (for example, by editing the server configuration JSON in the IDE to enable VM arguments override and appending them to args.vm.override.string):

--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED
--add-exports=java.naming/com.sun.jndi.url.ldap=ALL-UNNAMED
--add-exports=java.naming/com.sun.jndi.url.ldaps=ALL-UNNAMED
--add-exports=jdk.naming.dns/com.sun.jndi.dns=ALL-UNNAMED
--add-opens=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.lang.invoke=ALL-UNNAMED
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.net=ALL-UNNAMED
--add-opens=java.base/java.security=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.management/javax.management=ALL-UNNAMED
--add-opens=java.naming/javax.naming=ALL-UNNAMED
Lingua principale
Java
Stelle
36
Fork
32
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di redhat-developer/rsp-server

Tutte le issue di redhat-developer/rsp-server

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.