Accepted
Kotlin became the preferred language for Android development and offers concise test authoring. However, the SDK is a Java library consumed by Java and Android developers. Mixing Kotlin in the public API surface would:
- Require Kotlin stdlib as a hard consumer dependency
- Introduce Kotlin-specific null-safety annotations in public types
- Add friction for Java-only consumers
The decision was to bring Kotlin into tests (where its conciseness helps) without polluting the production public API.
- All production code (
src/main/java/) remains Java. Kotlin stdlib is included as acompilescope dependency — meaning it is a transitive runtime dependency for consumers: any project that declares this SDK as a dependency will receivekotlin-stdlibon its classpath. This has an Android jar-size implication. The public API surface still exposes only Java types. - All test code (
src/test/kotlin/) is written in Kotlin, usingkotlin-test-junitandkotlin-stdlib-jdk8intestscope. - The Maven build uses
kotlin-maven-pluginfor test compilation alongsidemaven-compiler-pluginfor Java.
- Enables: Concise, readable tests with Kotlin assertions; no Kotlin dependency burden on pure-Java SDK consumers.
- Requires:
kotlin-stdlibin compile scope — it is a transitive dependency for all SDK consumers, not just for internal build use. Android consumers should be aware of the additional jar size impact relative to Retrofit + Gson. - Sharp edge: Do not add Kotlin files under
src/main/java/. Althoughkotlin-maven-plugin's compile execution listssrc/main/javain itssourceDirs, the directory contains only.javafiles and no.ktfiles should ever be added there. Doing so would silently introduce Kotlin into the production source set, contradicting this ADR. - Note:
kotlin-stdlibin compile scope means it is resolved and placed on the classpath of any downstream project that depends on this SDK. This is a known trade-off; the footprint is small relative to other transitive deps.