Skip to content

Latest commit

 

History

History
30 lines (19 loc) · 2.19 KB

File metadata and controls

30 lines (19 loc) · 2.19 KB

ADR-0005: Kotlin for Tests, Java for Production Code

Status

Accepted

Context

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.

Decision

  • All production code (src/main/java/) remains Java. Kotlin stdlib is included as a compile scope dependency — meaning it is a transitive runtime dependency for consumers: any project that declares this SDK as a dependency will receive kotlin-stdlib on 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, using kotlin-test-junit and kotlin-stdlib-jdk8 in test scope.
  • The Maven build uses kotlin-maven-plugin for test compilation alongside maven-compiler-plugin for Java.

Consequences

  • Enables: Concise, readable tests with Kotlin assertions; no Kotlin dependency burden on pure-Java SDK consumers.
  • Requires: kotlin-stdlib in 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/. Although kotlin-maven-plugin's compile execution lists src/main/java in its sourceDirs, the directory contains only .java files and no .kt files should ever be added there. Doing so would silently introduce Kotlin into the production source set, contradicting this ADR.
  • Note: kotlin-stdlib in 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.