Guide · Kotlin experiment
Kotlin is a first-class JVM target.
The Kotlin projection rebuilds MyServiceBus around coroutines, receiver DSLs, reified types, Kotlin durations, and exhaustive results. It shares the Java transport and delivery runtime without inheriting Java futures or overload-heavy API shapes.
The shared JVM runtime and Java projection are the stable reference surfaces for this preview. The Kotlin projection passes the same delivery and staged-package gates, but its source API may evolve between previews as Kotlin and framework conventions are refined.
Install the projection
The Kotlin artifact sits above the shared JVM runtime. Add the Kotlin Jackson module when messages use data-class primary constructors.
Consume with suspending code
Kotlin owns both Consumer<T> and ConsumeContext<T>. The handler can call suspending messaging operations directly; MyServiceBus waits for the coroutine before acknowledging the delivery and propagates cancellation and failure into the shared receive pipeline.
Use a suspending function when a class is unnecessary
The first parameter binds the message directly. Additional application parameters resolve from the active per-message dependency-injection scope, and an optional matching ConsumeContext<T> exposes delivery metadata and messaging operations. A non-Unit result is returned as the correlated response.
The example registers both the class and function explicitly. The function-reference path uses bounded startup reflection and never scans the classpath.
In a larger application split across projects and packages, KSP can discover annotated functions and ordinary Kotlin consumer and handler classes during compilation. It emits the same finite registration list a developer could write manually, without startup scanning. Give each feature module a distinct catalog name, then register those few module catalogs in the application. Omit the KSP plugin and processor dependency to disable generation.
Configure and publish without Java ceremony
The registration DSL infers consumer and transport classes. The projected bus publishes with the familiar name instead of an Await suffix, while configured operations receive Kotlin-owned metadata contexts.
Coroutines
Bus, endpoint, mediator, request, response, and consumer operations suspend and participate in bidirectional cancellation.
Native facades
Kotlin owns the application-facing bus, mediator, endpoint, context, consumer, handler, and request-client types.
Shared behavior
Transports, topology, serialization, scopes, retry, fault, outbox, and settlement remain in the common JVM runtime.
Explicit escape
jvm { ... } exposes unprojected runtime capabilities without making Java syntax the default.
Request with reified response types
The scoped factory accepts Kotlin Duration and creates a suspending client without class literals. Multiple business outcomes become a sealed result, so when remains exhaustive and retains branch identity.
Dispatch locally with the same handler model
The mediator uses the shared scoped consumer pipeline but stays entirely in process. A suspending handler returns its response directly.
Coordinate a workflow with a Kotlin state machine
The experimental saga DSL keeps the recognizable C#/Java state-machine structure but uses Kotlin declarations and activity blocks. Delegated properties infer state and event identities, property references describe correlation and state storage, outgoing message types are reified, and then, send, and publish factories may suspend. The Java language projection remains deliberately closer to the C# declarative DSL; both JVM projections lower into the same definition, repository, topology, delivery, outgoing-message, and monitoring infrastructure.
The concise registration above creates a volatile process-local repository for development and tests. Production applications can provide repository capabilities and a scoped repository factory to the same sagaStateMachine registration. The Kotlin source shape is experimental even though its execution uses the existing shared JVM saga runtime.
Host it natively in Ktor
The server sample integrates through a Ktor application plugin instead of a Java-shaped bootstrap wrapper. One install(MyServiceBus) block declares the bus and optional application services; the plugin builds and owns the provider, startup, graceful shutdown with Kotlin Duration, readiness, and scopes. Suspending routes use the projected bus or open a scoped service block directly. The generic adapter remains sample-first while its ownership model settles. Its integration test runs publish, directed send, and correlated request/response through an isolated RabbitMQ broker and waits for the consumers to complete.
Java and Kotlin are not required to expose identical source APIs. The goal is equivalent topology, delivery, metadata, failure, and wire behavior through shapes that feel native in each language. See the platform parity guide for the broader contract.