The Adventures of a Kotlin-based Library Developer
summary
Covers concrete binary-compatibility pitfalls when migrating a Java library to Kotlin: named arguments are part of the API so renaming parameters breaks consumers; adding fields to a data class changes the generated copy/component signatures and data class copy changes break binary compatibility; static and property semantics change unless annotated. Recommends using Kotlin 1.4 library mode and JVM annotations like @JvmOverloads, @JvmStatic, @JvmField to preserve linkage, follow semantic versioning for breaking releases, and prefer Kotlin for new libraries rather than blind porting.
AI-written summary · about
chapters (7)
- 0:00Introduction and background
- 1:20Binary compatibility in Kotlin
- 9:36Migrating Java libraries to Kotlin
- 16:42Data classes and breaking changes
- 21:41Kotlin version compatibility
- 25:55Should you build libraries in Kotlin?
- 27:24Q&A session
related talks
36mBest practices for evolving Kotlin libraries
48mBuild Your Java/Kotlin Library
17mKotlin Library API Design and Compatibility Challenges
59mHow to Evolve Your Kotlin Library Painlessly for Clients
50mWriting Java-friendly Kotlin Code
52mPowered by Kotlin
31mA Kotlin Journey
22mBuilding SDKs - The Kotlin Way