DbosKotlinInternal class

[devhawk]

Initial experiment for including a wrapper around the various DBOS.* static methods to make them kotlin friendly. In particular:

• wrap all DBOS static methods as top level functions
• For methods that take a lambda like runStep and startWorkflow, make the lambda the last parameter to take advantage of trailing lambda syntax
• for methods that take a generic Exception parameter, hard code to Exception as Kotlin doesn't have checked exceptions
• use default params where possible (such as registerWorkflows instanceName and send idempotencyKey)

[Copilot]

Pull request overview

This PR introduces Kotlin-friendly wrappers for DBOS static methods to improve ergonomics for Kotlin developers. The changes leverage Kotlin language features like trailing lambda syntax, default parameters, and property accessors while maintaining compatibility with the underlying Java API.

Changes:

• Added DbosKotlinInternal.kt with top-level function wrappers for all DBOS static methods
• Reordered parameters to enable trailing lambda syntax for workflow and step functions
• Added Kotlin plugin configuration to the build file

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
transact/src/main/kotlin/dev/dbos/transact/DBOSExtensions.kt	New file providing Kotlin-idiomatic wrappers around DBOS static methods with trailing lambda support and default parameters
transact/build.gradle.kts	Added Kotlin JVM plugin version 2.3.0 and compiler configuration for Java 17 target

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kraftp]

To understand this better, how does it affect Java users? As a Kotlin user, how do I use this?

[devhawk]

To understand this better, how does it affect Java users? As a Kotlin user, how do I use this?

No effect on Java devs. @JvmSynthetic essentially hides the annotated item from Java so it's only visible from Kotlin.

For Kotlin devs, we expose top level functions instead of DBOS static functions. The package is still dev.dbos.transact so you would import each top level function individually (though you can import dev.dbos.transact.* to get all the top level functions at once). As documented above, there are a few changes to the top level functions for better kotlin dev experience.

Update: you can kind of get a sense of how this will look from dbos-inc/dbos-demo-apps#394. That demo app however has a local DBOS Extensions kotlin file as opposed to one in the main dbos transact package that this PR adds. So the imports are different but the code is basically the same

[chuck-dbos]

This looks harmless, maybe we merge it and see if it works easily in the demo then?

[devhawk]

This looks harmless, maybe we merge it and see if it works easily in the demo then?

I want to get 0.7 release out the door, then I agree