[DC] Xporter reports miss JavaScript-evaluated content: GraalVM JS engine fails to initialize under OSGi on Java 17

Summary

On Jira Data Center running Java 17, Xporter reports are generated but the JavaScript-evaluated content is missing or printed unevaluated (execution statuses, dates, conditional sections, condition-driven screenshots). The GraalVM JavaScript engine fails to initialize, so every template expression evaluated with JavaScript returns empty.

How to Reproduce

1. Jira Data Center on Java 17 with Xporter 7.4.5-j10.
2. Use a template that relies on JavaScript expressions (for example an Xray Test Execution template with execution-status blocks, or any field using a new Date() expression).
3. Export an issue with that template.

Expected result: JavaScript-evaluated fields are populated (execution statuses, formatted dates, conditional content).
Actual result: Those fields are empty or show the raw expression; the document is otherwise produced, so the report looks broken only where JavaScript is used.

Root cause

Nashorn is unavailable on Java 17 (expected). The GraalVM fallback fails: DocGraalVmEngine.initializeEngine() calls org.graalvm.polyglot.Engine.build(), which throws IllegalStateException "No language and polyglot implementation was found on the class-path" under Jira's OSGi class loading. Confirmed in SUPPORT-114314 DEBUG logs (nodes apjira03e2, apjira01e1, apjira01e2).

The failure was swallowed: initializeEngine() returned null, DocJsEngineBase threw a NullPointerException that the ScriptException-only catch did not handle, and every executeJavascript() then returned empty, so the export produced a document with empty JavaScript content instead of failing.

Dependency inconsistency

Engine 3.1.43 ships org.graalvm.polyglot:polyglot:23.1.1 with org.graalvm.js:js:23.0.7 and org.graalvm.js:js-scriptengine:23.1.5. The 23.1 polyglot isolation is fragile/incompatible with the 23.0 language on the classpath under OSGi. The same mix existed in engine 3.1.41 (when JS worked), so the failure is environmental/class-loading dependent rather than a clean version incompatibility.

Attempted fix (insufficient)

Setting the Thread Context ClassLoader to the polyglot classloader before Engine.build() did NOT resolve it (verified in customer DEBUG logs from the rebuilt custom build).

Candidate direction

Align the GraalVM/Truffle/JS dependencies to a single consistent version (see engine branch feature/graal-23) and/or load polyglot from the module-path. Needs testing in a real OSGi/DC environment; not reproducible locally. Also harden error handling so a JS-engine initialization failure fails loudly instead of producing reports with empty content (partly done: the GraalVM fallback catch was widened to Throwable and "No JS engine detected" is now logged at ERROR).