RegistryBinding, control annotations, and troubleshooting. What differs is the compile-time half: Kotlin code is processed by a KSP plugin, io.varianz.sdk.kotlin, not the Java annotation processor.
Setup
- The plugin id is
io.varianz.sdk.kotlin, notio.varianz.sdk. - Apply KSP first — the plugin throws unless
com.google.devtools.kspprecedes it in theplugins {}block. - Add JavaParser to
kspyourself — without it the processor dies withNoClassDefFoundError: com/github/javaparser/ast/Node. - Configure via the typed extension (
configure<VarianzKotlinExtension>) — the generatedvarianz {}accessor isn’t available when the plugin is applied dynamically.
pluginManagement repository setup is the same as Java’s.
Defining VPoints
- Annotation attributes require named arguments:
@VPoint(name = "…"), never positional. - Data-class fields map naturally:
valbecomes read-only in the schema,varread-write. Names convert to snake_case for CEL.
Not supported in @VPoint signatures
Two Kotlin features are rejected at compile time with clear errors:
@JvmInline value classparameters or returnssuspend fun— wrap the suspending call in a plain function and instrument that
Runtime and deployment
Everything on the Java page applies: thevarianz-agent must be attached (automatic for Gradle test/run, explicit for production launchers), RegistryBinding.init(...) + <Class>VPoints.bind(instance) at startup, and --enable-native-access=io.varianz.native_loader on Java 22+.
For session propagation with coroutines, carry the session in a context the caller thread can read — with OpenTelemetry, opentelemetry-extension-kotlin’s asContextElement() keeps Baggage flowing across suspensions. See Propagate sessions.
Testing
Kotlin tests use the JUnit 5 extension (see Testing → JUnit); a Kotest extension (io.varianz:varianz-kotest) provides the same session lifecycle for Kotest specs:
