com_r35157_nenjim-hubd-impl_ref/openspec/changes/archive/2026-09-02-80-introduce-javafx-runtime-service/proposal.md

Why

Modern JavaFX applications currently submit work through a static helper that silently initializes the JVM-wide toolkit. That hides an active shared lifecycle outside the Registry, Hub startup order, constructor dependency graph, and started-process snapshot established by issues #77 through #79.

What Changes

• Add a minimal JavaFxRuntimeService component API with only non-null asynchronous JavaFX Application Thread submission.
• Add one reference object that is both the service and a single-attempt NenjimProcess; only its start() initializes JavaFX, waits for readiness, and disables implicit exit.
• Construct and register that object as nenjim.javafx-runtime.service, start it before enabled JavaFX applications, and record it through the existing successful-start mechanism.
• Constructor-inject the same service into Mission Control and Process Manager and migrate the four dormant modern JavaFX applications to the same model.
• Remove the static JavaFxRuntime utility and document explicit runtime ownership and ordering.

Capabilities

Added Capabilities

• javafx-runtime-service: define the public service, process lifecycle, submission rules, consumer injection, and deliberately absent operations.

Modified Capabilities

• nenjim-component-registry: add Hub construction, registration, ordering, fail-fast behavior, and started-process tracking for the JavaFX runtime.
• nenjim-process-manager: replace the implicit static runtime dependency with the injected service while preserving polling and presentation behavior.

Impact

Affected code is limited to the JavaFX runtime boundary, six existing modern JavaFX consumers, Hub composition/startup, directly relevant documentation, and this active OpenSpec change. No configuration, dependency discovery, events, stop/restart lifecycle, window management, health monitoring, headless emulation, or broad legacy migration is introduced.