API and capability status · Current preview
What can I use today, and what could change in the future?
Start with the developer capability, then compare the stable C# and Java reference entry points, the alignment choice, the evidence behind it, and the remaining compatibility risk. Kotlin is a separate experimental projection over the same JVM behavior. Similar means recognizable contract and behavior—not an unversioned promise of source or database compatibility.
Verified preview means the capability exists in both clients and has focused automated evidence. MVP preview is usable for evaluation but has named production gates left. Experimental means the design or operational contract can still change materially. None of these labels means a long-term stable API yet.
Kotlin applications select myservicebus-kotlin for suspending consumers, endpoints, requests, and mediator operations; receiver DSLs; reified types; Kotlin durations; and sealed results. The Java and Kotlin frontends have their own endpoint and context contracts while sharing the JVM transport, topology, serialization, retry, settlement, and wire implementation. The Kotlin source API remains experimental for this preview; the Java projection is the stable JVM reference. See the Kotlin guide for the current surface and Ktor integration.
Aligned + interoperable identifies the pinned common wire contract. Idiomatic equivalent keeps behavior while adapting the API to C# or Java. Deliberate divergence and MyServiceBus-native identify choices we intend to own. Temporary gap means the current difference is incomplete work, not a desired compatibility boundary.
The table is intentionally curated around decisions an application team makes. It does not list every registration overload, generated adapter, internal descriptor, or test case. The repository keeps that detailed maintainer ledger separately; a capability reaches this page only when its public behavior and readiness can be stated clearly.
| Developer capability | C# API | Java API | Alignment or divergence | Readiness | What could change |
|---|---|---|---|---|---|
| Publish events | IPublishEndpoint.Publish | PublishEndpoint.publish | Aligned + interoperable — familiar intent and verified 8.5.1 wire subset. | Verified preview | Transport acceptance edge cases still have open production gates. |
| Send commands | ISendEndpoint.Send | SendEndpoint.send | Aligned + interoperable — familiar directed send and endpoint addressing. | Verified preview | Address normalization and broker options may evolve before 1.0. |
| Consume messages | IConsumer<T>.Consume | Consumer<T>.consume | Idiomatic equivalent — same responsibility and behavior; Java does not copy .NET syntax. | Verified preview | Registration overloads may simplify; the typed model is a core direction. |
| Request and response | IRequestClient<T>.GetResponseAsync | RequestClient<T>.getResponse | Idiomatic equivalent — familiar correlation and faults; Java uses class tokens where generic types are erased. | Verified preview | Convenience overloads and multi-response ergonomics may expand. |
| Bus configuration and DI | AddServiceBus + UsingRabbitMq / UsingAzureServiceBus | ServiceCollection or standalone bus factory + using… | Deliberate divergence — C# stays MassTransit-familiar; Java follows Java composition and lifecycle idioms. | Verified preview | Java ecosystem adapters may expand without forcing one container into the core API. |
| In-process mediator | IMediator.Send / Publish | Mediator.send / publish | MyServiceBus-native emphasis — MediatR-style semantics on the shared handler runtime; not MassTransit mediator compatibility. | Verified preview | Handler pipelines may grow; mediator remains segregated from the bus API. |
| Consumer methods and handlers | [Consumer] + AddHandler | @MessageConsumer + addHandler | MyServiceBus-native — explicit mediator-friendly handlers and generated/reflected method consumers. | Verified preview | Declaration and registration conveniences may grow. |
| Transactional Bus Outbox | UsePostgreSql + AddPostgreSqlOutboxDelivery | useTransaction + PostgreSqlOutboxDelivery.create | Deliberate divergence — normalized MyServiceBus C# ↔ Java schema, not MassTransit table compatibility. | MVP preview | Consumer Outbox, cleanup, SQL Server, and production crash gates remain. |
| Transport portfolio | RabbitMQ + Azure Service Bus | RabbitMQ + Azure Service Bus | Deliberate scope — one portable profile per supported broker, not MassTransit transport breadth. | Verified preview | New transports may be added only with matching C# and Java behavior and evidence. |
| Schedule or delay messages | IMessageScheduler + IScheduleMessageProvider | MessageScheduler + ScheduleMessageProvider | Idiomatic equivalent — MassTransit-familiar C# surface, Java-native time/async types, and explicit volatile or durable providers. | MVP preview | PostgreSQL outbox delayed intent works; persisted cancellation, recurring schedules, and broker/Quartz adapters remain. |
| Runtime monitoring | AddServiceBusMonitoring + PostgreSqlOutboxHealth | MonitoringServices.addMonitoring + PostgreSqlOutboxHealth | MyServiceBus-native — own collector/dashboard model plus OpenTelemetry-compatible application telemetry. | Experimental | Outbox export, persistence, security, and dashboard operations are incomplete. |
| Generated registration and dispatch | C# source generator | JSR 269 annotation processor | MyServiceBus-native — compile-time path for lower-reflection startup and mediator dispatch. | Verified preview | Generated coverage will expand with the runtime surface. |
Wire interoperability is tested against MassTransit 8.5.1 and only for the documented common subset. Current MassTransit documentation is useful background for familiar concepts such as send and publish ↗, requests ↗, the outbox ↗, and scheduling ↗. MyServiceBus documents and tests its own contract because later releases may evolve independently.
For the exact wire boundary, transport versions, and exclusions, use the interoperability matrix. For the PostgreSQL transaction boundary and remaining promotion work, use the Transactional Outbox guide. For volatile timers, persisted delayed intent, and provider guarantees, use the message scheduling guide.
Equivalent experience does not mean identical syntax
C# deliberately keeps the MassTransit-familiar shape where it helps existing teams. Java expresses the equivalent responsibility through Java naming, futures, class tokens, explicit lifecycle, and composition idioms. Kotlin projects that responsibility into coroutines, reified types, and Kotlin-owned contexts without changing the shared JVM behavior. Generated registration exists in both stable ecosystems, but its compiler mechanics belong in the AOT and generation guide, not in this adoption table.