Why does ScriptEngineManager's getEngineByName return null for JavaScript?

I’m using GraalVM to run JavaScript code within my Java application. I have included the following Maven dependencies in my project:

<dependency>
  <groupId>org.graalvm.js</groupId>
  <artifactId>js</artifactId>
  <version>24.1.2</version>
  <type>pom</type>
</dependency>
<dependency>
  <groupId>org.graalvm.polyglot</groupId>
  <artifactId>polyglot</artifactId>
  <version>24.1.2</version>
</dependency>
<dependency>
  <groupId>org.graalvm.js</groupId>
  <artifactId>js-scriptengine</artifactId>
  <version>24.1.2</version>
</dependency>

I am attempting to obtain the JavaScript engine using this code:

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("JavaScript");

However, it seems to return null on certain systems, while it works perfectly on others. What might be causing this discrepancy? How can I ensure the JavaScript engine is consistently available?

The null return usually occurs if the js-scriptengine dependency isn’t present at runtime, even if it compiles correctly. I’ve experienced this issue during deployments where Maven failed to include all dependencies in the final JAR. Ensure that all three GraalVM dependencies are in your runtime classpath, particularly the js-scriptengine artifact. Also, be cautious of version mismatches; all dependencies must align with the same version number. If creating a fat JAR, verify that the META-INF/services files from js-scriptengine are correctly merged, as these files are essential for the ScriptEngineManager to locate service providers.

check ur module-path setup if ur using java 9+. graalvm’s js engine gets blocked by the module system sometimes. add --add-modules=org.graalvm.js to ur jvm args or just use the polyglot api directly instead of scriptenginmanager - it’s way more reliable.

This issue often arises due to classpath problems or conflicting script engine implementations. The ServiceLoader may fail to locate the GraalVM JavaScript engine factory correctly. Instead of the generic ‘JavaScript’ name, try using ‘graal.js.’ This tends to be more reliable. Ensure that your runtime environment aligns with your build setup; I’ve encountered scenarios where engines operate without issue during development but fail in production due to discrepancies in JVM configurations or absent native libraries. In past experiences with these types of embedded script engines, I utilized manager.getEngineFactories() to verify what was being loaded. It’s also a good practice to implement a fallback or robust error handling in cases where the engine is unavailable.