NPE in com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.createRuntime(): "jdk.internal.module.Modules.JLA" is null

[novos40]

Describe GraalVM and your environment :

• graalvm-jdk-21.0.4+8.1, OpenJDK-21
• CE
• JDK 21
• OS and OS Version: Windows 10
• Architecture: intel 64
• The output of java -Xinternalversion:

OpenJDK 64-Bit Server VM (21+35-2513) for windows-amd64 JRE (21+35-2513), built on 2023-08-09T20:25:10Z by "mach5one" with MS VC++ 17.1 (VS2022)

Have you verified this issue still happens when using the latest snapshot?
No. Using stable version v24.0.2

Describe the issue
I have built polyglot OSGi bundle with python support to run on apache felix OSGi container. The goal is to run python on java. Everything was working with v23.1.1. Now I'm getting NPE

Expected behavior
Correct initialization or at least meaningful diagnostic

Additional context
Was working on JDK-17 and v23.1.1 with
-Dpolyglotimpl.TraceClassPathIsolation=true
-Dpolyglotimpl.DisableClassPathIsolation=true

I was having problems with native python libraries loading (another issue). I was hoping that latest polyglot version would resolve that. It looks like something is not initialized correctly. (i.e. "jdk.internal.module.Modules.JLA" is null)

OSGi container uses org.apache.atomos to load all JDK modules. They are correctly loaded and exposed as bundles. Everything works except polyglot initialization.

Details

Caused by: java.lang.ExceptionInInitializerError
at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.createRuntime(HotSpotTruffleRuntimeAccess.java:84)
at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.getRuntime(HotSpotTruffleRuntimeAccess.java:75)
at com.oracle.truffle.api.Truffle.createRuntime(Truffle.java:145)
at com.oracle.truffle.api.Truffle$1.run(Truffle.java:176)
at com.oracle.truffle.api.Truffle$1.run(Truffle.java:174)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at com.oracle.truffle.api.Truffle.initRuntime(Truffle.java:174)
at com.oracle.truffle.api.Truffle.(Truffle.java:63)
at com.oracle.truffle.runtime.enterprise.EnterpriseTruffle.supportsEnterpriseExtensions(stripped:21)
at com.oracle.truffle.polyglot.enterprise.EnterprisePolyglotImpl.getPriority(stripped:518)
at java.base/java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:473)
at java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
at java.base/java.util.TimSort.sort(TimSort.java:220)
at java.base/java.util.Arrays.sort(Arrays.java:1308)
at java.base/java.util.ArrayList.sort(ArrayList.java:1804)
at java.base/java.util.Collections.sort(Collections.java:178)
at org.graalvm.polyglot.Engine.loadAndValidateProviders(Engine.java:1656)
at org.graalvm.polyglot.Engine$1.run(Engine.java:1732)
at org.graalvm.polyglot.Engine$1.run(Engine.java:1727)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at org.graalvm.polyglot.Engine.initEngineImpl(Engine.java:1727)
at org.graalvm.polyglot.Engine$ImplHolder.(Engine.java:190)
at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
...
Caused by: java.lang.NullPointerException: Cannot invoke "jdk.internal.access.JavaLangAccess.addExports(java.lang.Module, String, java.lang.Module)" because "jdk.internal.module.Modules.JLA" is null
at jdk.internal.module.Modules.addExports(Modules.java:105)
at com.oracle.truffle.runtime.ModulesSupport.addExports0(Native Method)
at com.oracle.truffle.runtime.ModulesSupport.(ModulesSupport.java:69)
... 125 more

[novos40]

I was able to make it work by collecting all relevant jars (using maven's dependency:copy-dependencies) and placing them all on the module path. This works for both OpenJDK and graalvm JDK. I still think this should be fixed as I should be able to collect all modules into a single jar and run it off the class path (with -Dpolyglotimpl.DisableClassPathIsolation=true or some other relevant settings). One of the main points of using OSGi is the ability to create per-feature bundle/jar and enable that feature for a particular deployment by simply placing the jar into a bundle folder. Now instead of a single bundle jar I'd have to manage 31 module jars to enable this single feature of running python code in our container.