Kotlin Library API Design and Compatibility Challenges
summary
Covers concrete compatibility failures and concrete fixes: adding a parameter to a public method creates a new signature and breaks binary compatibility; solution is to keep the old method as a synthetic shim annotated @Deprecated(level = HIDDEN) that forwards to the new one. Recommends the JetBrains binary-compatibility-validator Gradle plugin and using API dump diffs, cites Java Language Spec chapter 13 and semantic versioning, shows sealed interfaces/value wrappers to avoid exhaustive enum breaks, and uses RequiresOptIn for experimental APIs.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:29API safety and compatibility
- 3:36Source vs binary compatibility
- 5:22Binary Compatibility Validator
- 6:46Adding function arguments safely
- 9:25Lambda parameters and interfaces
- 11:52Enums and sealed classes
- 13:40Data classes updates
- 15:06Experimental APIs and versioning
- 15:49Library development best practices
- 16:30Conclusion and Q&A
related talks
42mEvolving your Kotlin API painlessly for clients
42mEvolving your Kotlin API painlessly for clients
23mMetadawhat? Managing compatibility of your Kotlin apps and libraries
35mMastering API Visibility in Kotlin
59mHow to Evolve Your Kotlin Library Painlessly for Clients
41m10 Tips to Make Libraries Kotlin-Friendly
22mBuilding SDKs - The Kotlin Way
48mBuild Your Java/Kotlin Library
