Analysis: where GraalJS / TypeScript are used, and what making them optional or removing them would take

Start with the module and class inventories in the issue, then trace the named Maven dependencies and Java imports, especially the TscWatcherService and its publisher handler. Compare each runtime feature with the listed Java equivalents and record remaining gaps, including platform-internal JS use. The result should be an inventory, hard coupling list, recommendation with effort estimate, and follow-up sequence; the issue calls for measured no-JS build comparisons as well.

Goal

Analyse where the platform depends on GraalJS, and with it the TypeScript toolchain. Then work out what it would take to make that dependency optional, meaning a runtime that boots without it, or to remove it entirely.

This issue is for the analysis only. Its outcome should be an inventory, a gap list, and a recommendation with an effort estimate. Implementation would follow in separate issues.

Why now

• Applications have moved to Java. Applications can now be built entirely on the Java path: AOT-compiled module jars, @Controller / @Entity / @Scheduled / @Listener / @Websocket, and Flowable JavaDelegates. One production solution we run on 14.93.0 ships 57 module jars with 1206 compiled classes and zero .ts files. It still carries the whole JS stack at runtime.
• Footprint. The JS stack accounts for a large part of the image size and of the memory used outside the heap. We had repeated kernel OOM kills on a 2 GiB task, see #7963.
• We plan to retire GraalJS in the near future. A fact-based map of what depends on it is the prerequisite.

What we already know (14.93.0, commit 862f6d1a3e)

Runtime artefacts (Gaia 14.93.0 image)

• The GraalJS/Truffle jars total about 68 MiB in BOOT-INF/lib (all 25.4.4.1.1):
  • js-language 27.9 MB, icu4j 18.6 MB, truffle-api 17.0 MB, regex 3.9 MB;
  • also chromeinspector-tool, profiler-tool, truffle-runtime, polyglot and others.
• The base image also ships Node (/usr/bin/node, npm), esbuild and tsc, with about 52 MB of node_modules.
• The JVM is Corretto 21, which has no Graal JIT. EngineCreator sets engine.WarnInterpreterOnly=false, so JS most likely runs interpreter-only.

Maven modules

• Direct GraalVM dependencies exist only in modules/engines/engine-graalium/execution (polyglot, js-community, inspect-community) and components/api/api-log.
• dirigible-components-engine-javascript is a dependency of 20 modules:
  • api: api-component, api-http, api-indexing, api-messaging, api-mongodb, api-net, api-platform, api-qunit, api-rabbitmq, api-security, api-template, api-test;
  • engine: engine-bpm-flowable, engine-camel, engine-di, engine-jobs, engine-listeners, engine-template-javascript, engine-typescript, engine-websockets.
• dirigible-components-engine-typescript is a dependency of group-engines and ide-workspace.

Java code importing org.graalvm, outside tests

• engine-graalium (12 classes): ContextCreator, EngineCreator, GraalJSCodeRunner, GraalJSFileSystem, GraalJSSourceCreator, ValueTransformer, Module, the DirigibleJavascript* hooks/interceptors.
• engine-javascript: JavascriptEndpoint, JavascriptHandler.
• engine-di: ComponentMetadataRegistry, ComponentRegister, ComponentService (TypeScript decorator-based components).
• engine-bpm-flowable: DirigibleCallDelegate, DirigibleTaskListener (JS handlers on BPMN tasks).
• engine-camel: DirigibleJavaScriptInvokerImpl.
• engine-websockets: WebsocketProcessor.
• engine-template-javascript: JavascriptGenerationEngine (the IDE generators and templates).
• api-component: ComponentFacade.

JS/TS SDK

• 241 .js/.ts/.mjs files under components/api/*/META-INF/dirigible.
• Of these, 134 are in api-modules-javascript, 31 in api-utils and 16 in api-http.

Java equivalents that already exist in engine-java

• ControllerClassConsumer, HandlerClassConsumer, ListenerClassConsumer, ScheduledClassConsumer, WebsocketClassConsumer, and EntityClassConsumer in data-store-java.

The TypeScript toolchain

• TypeScriptService transpiles on publish with esbuild, running it as a process.
• TscWatcherService runs a long-lived tsc --watch Node process over the registry.
• This shows how tightly the pieces are coupled: on 14.93.0, DIRIGIBLE_TSC_WATCH_SERVICE_ENABLED=false prevents the application from starting. TscWatcherServicePublisherHandler is an unconditional @Component that needs the conditional TscWatcherService bean.

Questions the analysis should answer

1. Full inventory. For every artefact type and engine that executes JS/TS at runtime, list it and whether a Java equivalent exists. That covers HTTP endpoints, jobs, listeners, BPMN delegates/listeners, websockets, Camel invokers, DI components, extensions, templates/generators, tests (QUnit), security hooks and so on. Is the Java equivalent complete, partial or missing?
2. Platform-internal use. Which built-in features use JS themselves, not just on behalf of user projects? For example: IDE services, generators/templates, system jobs, extension points, the intent engine, api-* facades only reachable from JS, and api-log.
3. Optional first. What would a "no-JS" runtime profile need? Excluding engine-graalium / engine-javascript / engine-typescript (and Node/esbuild/tsc in the image) must leave a bootable app. Which beans and modules hard-depend on them today, like the TscWatcher example above?
4. Removal impact.
   • What breaks for existing JS/TS projects?
   • Is a migration path needed (tooling, docs, a deprecation window)?
   • What happens to the JS SDK (api-modules-javascript etc.)?
   • What happens to the IDE's JS/TS features: editor, debugger via inspect-community, templates?
5. Expected gains, measured. Compare the image size, boot time, heap and metaspace / native memory (NMT), and thread count of a no-JS build against the current one, on the same Java-only application.
6. Risks and order of work. A suggested sequence. For example: decouple the beans (make it optional), then a no-JS profile or image variant, then deprecation, then removal. List the risks of each step.

Expected output

• An inventory table: feature / artefact → JS-only, Java available, or both → gap.
• A list of hard couplings that block an optional JS engine, each with file references.
• A recommendation (optional vs removal) with a rough effort estimate, plus follow-up issues.