Mastering API Visibility in Kotlin
summary
Kotlin gives concrete levers: use explicit API mode to force explicit visibility and public return types so library signatures don’t change by type inference; prefer internal for module-only implementations and test visibility; mark inline helpers with published API to allow inlining without leaking non‑public symbols; annotate JVM-only helpers with jvmSynthetic to hide them from Java; use @Deprecated with a replacement string or the hidden deprecation level to migrate or remove APIs without breaking binary compatibility.
AI-written summary · about
chapters (22)
- 0:00Start
- 0:31Mastering Api Visibility in Kotlin
- 2:47Create Minimal Apis
- 3:31Why Do We Want Minimal Apis
- 4:22Unused Public Api
- 4:58Remove a Public Api
- 7:13Hidden
- 8:09Easier To Learn
- 10:18Default Visibility in Kotlin
- 13:30Testing
- 16:09The Jvm Synthetic Annotation
- 16:52Explicit Api Mode
- 17:23To Enable Explicit Api Mode
- 18:09Progressive Mode
- 20:16Explicit Types
- 23:20Published Api
- 24:20Opt-In Apis
- 29:32Resources
- 30:20Sum Up Mastering Api Visibility in Kotlin
- 31:36Why Was Package Level Visibility Removed in Kotlin
- 32:17What Software I Used To Create this Presentation
- 34:56Thank You
related talks
42mEvolving your Kotlin API painlessly for clients- 42mEvolving your Kotlin API painlessly for clients
17mKotlin Library API Design and Compatibility Challenges
22mBuilding SDKs - The Kotlin Way
36mBest practices for evolving Kotlin libraries
42mKotlin Not-to-Do List - What we should avoid doing in Kotlin
41m10 Tips to Make Libraries Kotlin-Friendly
42mIdiomatic Interop with Kotlin