sdbus-kotlin
sdbus-kotlin is a high-level D-Bus library for Kotlin Multiplatform, born as a port of sdbus-c++. It provides typed client proxies and service adaptors over D-Bus, plus a Gradle plugin that generates the Kotlin bindings from D-Bus introspection XML.
The same common API is published for three targets:
| Target | Backend |
|---|---|
jvm | An owned D-Bus connection — junixsocket transport with a pure-Kotlin marshaller and dispatcher (as of 0.5.0; no dbus-java, no native code) |
linuxX64 | sd-bus via libsystemd (cinterop) |
linuxArm64 | sd-bus via libsystemd (cinterop) |
Application code is identical on every target — the choice of backend is a deployment decision. For the capability-by-capability contract between the JVM and native backends, including which test suite pins each behavior and the few known divergences, see docs/BACKENDS.md.
Where to start
The public API flows from a connection to typed objects:
Open a connection. Use one of the
create…BusConnectionfactories — for examplecreateSystemBusConnection(),createSessionBusConnection(), or the direct/server fd factories on native. The result is a Connection, which owns the I/O event loop (startEventLoop()/stopEventLoop()).Get a proxy or export an object.
createProxy(...)returns a Proxy for talking to a remote service;createObject(...)returns an Object you register interfaces on with theaddVTable { ... }DSL to serve calls, properties, and signals.Make typed calls. Issue method calls via the
call/argsDSL (synchronous orsuspend), read and write properties through property delegates (values()/changes()flows for observation), and subscribe to signals withsignalFlow. Names are wrapped in value classes —BusName,InterfaceName,MemberName,ObjectPath,PropertyName— and timeouts usekotlin.time.Duration.
Most users do not call this surface by hand: the codegen Gradle plugin (com.monkopedia.sdbus.plugin) generates the proxy and adaptor types from introspection XML (conventionally placed in src/dbusMain), giving you fully typed interfaces to implement and consume.
For runnable quick-starts — Gradle setup for JVM and native, code generation, and complex-type handling — see the README. For a worked server-side example, see samples/demo-service.
API stability
0.6.0 is the 1.0-polish release — a post-0.5.0 review applied a final wave of renames and deprecations to the public surface; 1.0 will freeze it, dropping the names deprecated in 0.6.0. Compatibility is enforced in CI with binary-compatibility-validator (JVM and klib API dumps are checked in under api/), so any change to the public surface is an explicit, reviewed event. The per-release migration notes are in the CHANGELOG.
sdbus-kotlin is a high-level D-Bus library for Kotlin Multiplatform, born as a port of sdbus-c++. It provides typed client proxies and service adaptors over D-Bus, plus a Gradle plugin that generates the Kotlin bindings from D-Bus introspection XML.
The same common API is published for three targets:
| Target | Backend |
|---|---|
jvm | An owned D-Bus connection — junixsocket transport with a pure-Kotlin marshaller and dispatcher (as of 0.5.0; no dbus-java, no native code) |
linuxX64 | sd-bus via libsystemd (cinterop) |
linuxArm64 | sd-bus via libsystemd (cinterop) |
Application code is identical on every target — the choice of backend is a deployment decision. For the capability-by-capability contract between the JVM and native backends, including which test suite pins each behavior and the few known divergences, see docs/BACKENDS.md.
Where to start
The public API flows from a connection to typed objects:
Open a connection. Use one of the
create…BusConnectionfactories — for examplecreateSystemBusConnection(),createSessionBusConnection(), or the direct/server fd factories on native. The result is a Connection, which owns the I/O event loop (startEventLoop()/stopEventLoop()).Get a proxy or export an object.
createProxy(...)returns a Proxy for talking to a remote service;createObject(...)returns an Object you register interfaces on with theaddVTable { ... }DSL to serve calls, properties, and signals.Make typed calls. Issue method calls via the
call/argsDSL (synchronous orsuspend), read and write properties through property delegates (values()/changes()flows for observation), and subscribe to signals withsignalFlow. Names are wrapped in value classes —BusName,InterfaceName,MemberName,ObjectPath,PropertyName— and timeouts usekotlin.time.Duration.
Most users do not call this surface by hand: the codegen Gradle plugin (com.monkopedia.sdbus.plugin) generates the proxy and adaptor types from introspection XML (conventionally placed in src/dbusMain), giving you fully typed interfaces to implement and consume.
For runnable quick-starts — Gradle setup for JVM and native, code generation, and complex-type handling — see the README. For a worked server-side example, see samples/demo-service.
API stability
0.6.0 is the 1.0-polish release — a post-0.5.0 review applied a final wave of renames and deprecations to the public surface; 1.0 will freeze it, dropping the names deprecated in 0.6.0. Compatibility is enforced in CI with binary-compatibility-validator (JVM and klib API dumps are checked in under api/), so any change to the public surface is an explicit, reviewed event. The per-release migration notes are in the CHANGELOG.
sdbus-kotlin is a high-level D-Bus library for Kotlin Multiplatform, born as a port of sdbus-c++. It provides typed client proxies and service adaptors over D-Bus, plus a Gradle plugin that generates the Kotlin bindings from D-Bus introspection XML.
The same common API is published for three targets:
| Target | Backend |
|---|---|
jvm | An owned D-Bus connection — junixsocket transport with a pure-Kotlin marshaller and dispatcher (as of 0.5.0; no dbus-java, no native code) |
linuxX64 | sd-bus via libsystemd (cinterop) |
linuxArm64 | sd-bus via libsystemd (cinterop) |
Application code is identical on every target — the choice of backend is a deployment decision. For the capability-by-capability contract between the JVM and native backends, including which test suite pins each behavior and the few known divergences, see docs/BACKENDS.md.
Where to start
The public API flows from a connection to typed objects:
Open a connection. Use one of the
create…BusConnectionfactories — for examplecreateSystemBusConnection(),createSessionBusConnection(), or the direct/server fd factories on native. The result is a Connection, which owns the I/O event loop (startEventLoop()/stopEventLoop()).Get a proxy or export an object.
createProxy(...)returns a Proxy for talking to a remote service;createObject(...)returns an Object you register interfaces on with theaddVTable { ... }DSL to serve calls, properties, and signals.Make typed calls. Issue method calls via the
call/argsDSL (synchronous orsuspend), read and write properties through property delegates (values()/changes()flows for observation), and subscribe to signals withsignalFlow. Names are wrapped in value classes —BusName,InterfaceName,MemberName,ObjectPath,PropertyName— and timeouts usekotlin.time.Duration.
Most users do not call this surface by hand: the codegen Gradle plugin (com.monkopedia.sdbus.plugin) generates the proxy and adaptor types from introspection XML (conventionally placed in src/dbusMain), giving you fully typed interfaces to implement and consume.
For runnable quick-starts — Gradle setup for JVM and native, code generation, and complex-type handling — see the README. For a worked server-side example, see samples/demo-service.
API stability
0.6.0 is the 1.0-polish release — a post-0.5.0 review applied a final wave of renames and deprecations to the public surface; 1.0 will freeze it, dropping the names deprecated in 0.6.0. Compatibility is enforced in CI with binary-compatibility-validator (JVM and klib API dumps are checked in under api/), so any change to the public surface is an explicit, reviewed event. The per-release migration notes are in the CHANGELOG.