← Back to all briefings
Developer 6 min read Published Updated Credibility 40/100

Developer Briefing — Kotlin 1.4 Release Candidate

JetBrains published the Kotlin 1.4 release candidate on 30 July 2020, locking in new type inference, coroutine tooling stability, and multiplatform compiler improvements ahead of the long-term 1.4 support window.

Zeph Tech Research Lead

Research lead, Zeph Tech

Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

JetBrains announced the Kotlin 1.4 release candidate on 30 July 2020, marking feature freeze for the first major Kotlin release since 1.3.70. The RC cements new type inference, multiplatform compiler changes, and coroutine debugging improvements that teams will support through the 1.4 maintenance stream. Because the RC closely mirrors general availability, engineering managers can treat this build as the baseline for performance testing, dependency alignment, and migration of shared libraries that will underpin Android, JVM, JS, and Native targets for the next year.

What changed

  • New type inference improves handling of callable references, builder-style DSLs, and smart casts without explicit type arguments. Many overload-heavy APIs (e.g., JSON serializers, HTTP clients, test matchers) now infer types that previously required manual hints.
  • Multiplatform unification delivers a single standard library artifact with hierarchical project structure, reducing duplicate source sets and clarifying expected/actual declarations. Shared business logic can target JVM, JS, and Native with fewer workarounds.
  • Coroutine tooling gains structured concurrency diagnostics, debugger support for coroutines in IntelliJ IDEA, and improved exception handling for nested scopes. Developers can now see coroutine names, states, and parent/child relationships in debugger views.
  • Gradle multiplatform plugin updates streamline metadata publishing and default to hierarchical project layouts, reducing the custom Gradle scripting that teams maintained for cross-platform builds.
  • Explicit API mode allows library authors to enforce visibility and return-type declarations, supporting stable public APIs and better binary compatibility across patch releases.
  • Sam-with-receiver and functional interface improvements align Kotlin lambdas with Java interop expectations, easing migrations for Spring, Micronaut, and Android Jetpack projects.
  • Language and standard library refinements include new contracts in the standard library, Duration API updates, and opt-in requirement annotations to discourage accidental use of unstable APIs.

Developer workflow impact

  • Android, server, and multiplatform codebases can upgrade with clearer compatibility guarantees before Kotlin 1.4 GA, tightening alignment with Jetpack Compose, Ktor, and serialization releases that depend on 1.4 APIs.
  • Type inference fixes reduce compile-time errors when migrating large DSLs (e.g., Gradle build scripts, serialization schemas), cutting down local patching of third-party libraries. Teams see fewer ambiguous-call errors and less need for temporary @Suppress annotations.
  • Multiplatform unification lowers artifact sprawl and CI build times, important for teams distributing shared business logic to mobile and web clients. Developers can centralize common code and treat platform-specific source sets as thin adapters.
  • Coroutine debugging support improves incident response for production outages that involve async pipelines, enabling on-call engineers to trace stalled jobs and cancellation propagation directly in IDE tooling.
  • Explicit API mode provides stronger guarantees for internal SDKs and platform teams, ensuring public APIs carry explicit return types and visibility modifiers before publication.

Risks and breaking considerations

  • Some third-party libraries have not yet published 1.4-compatible artifacts; enabling 1.4 RC in apps without updating dependencies can surface binary compatibility errors or missing stdlib functions.
  • Type inference changes may alter overload resolution in edge cases, potentially selecting different functions than 1.3.x. Critical DSLs should be regression-tested with property-based tests or golden files.
  • Multiplatform metadata changes can break consumers that rely on older Gradle metadata formats. Repositories using private Maven proxies should flush outdated metadata caches before adopting the RC.
  • Coroutine debugging metadata introduces minor runtime overhead; performance-sensitive services should benchmark the RC with debugging disabled and with sampling enabled to quantify impact.
  • Explicit API mode is opt-in, but enabling it mid-release may fail builds if existing public APIs lack explicit visibility or return types. Plan phased adoption with module-by-module enforcement.

Migration and testing guidance

  • Create a feature branch that pins the Kotlin Gradle plugin and compiler to 1.4.0-rc, then run full CI to collect compiler diagnostics and binary compatibility errors.
  • Exercise multiplatform builds with the new hierarchical project structure; validate that published metadata resolves correctly for consumers on Maven Central and internal artifact repositories.
  • Run Android and server benchmarks to compare build times, coroutine scheduler behavior, and memory footprint between 1.3.72 and 1.4 RC. Include tasks that stress kapt, annotation processors, and incremental compilation.
  • Enable coroutine debugger integration in IntelliJ IDEA 2020.1+ for staging environments and verify that coroutine names and hierarchies appear in debugging sessions without corrupting trace data.
  • Adopt explicit API mode in internal libraries that ship shared APIs to other teams. Start in warning-only mode to inventory needed annotations and explicit types before enforcing the rule in CI.
  • Review Gradle plugin updates for metadata publication and check that POM files include correct module names and platform attributes. Misconfigured metadata can break dependency resolution for consumers still on Kotlin 1.3.

Operational playbook

  • Dependency readiness: Track Jetpack Compose, Ktor, kotlinx.serialization, Arrow, and coroutine libraries for 1.4-compatible releases. Avoid upgrading app modules until core dependencies publish RC-aligned builds.
  • Build infrastructure: Update CI images to include Kotlin 1.4 RC compiler and Gradle plugin versions. Validate caching layers (Gradle build cache, remote cache) after the metadata format change.
  • IDE rollout: Encourage teams to install the Kotlin 1.4 RC plugin in IntelliJ IDEA or Android Studio canary channels, then gather feedback on code completion accuracy and coroutine debugger stability.
  • API governance: Use explicit API mode to enforce binary compatibility for platform SDKs. Document expectations for public classes, default method bodies, and opt-in annotations to minimise churn for downstream consumers.
  • Release communication: Notify QA and product stakeholders that RC adoption may temporarily slow release cadence while dependency updates propagate and caches warm.

Architecture and security notes

  • Improved type inference reduces unsafe casts and unchecked nullability workarounds, lowering runtime defects in serialization, configuration loading, and network clients.
  • Multiplatform unification simplifies cryptography and identity modules shared across Android, iOS (via Kotlin/Native), and JavaScript, ensuring consistent policy enforcement for authentication flows.
  • Coroutine debugger clarity strengthens incident response for asynchronous workflows, reducing mean time to detect stuck jobs that could otherwise impact SLAs.
  • Explicit API mode acts as a governance control, requiring deliberate visibility and return types before libraries ship, which helps maintain backward compatibility for regulated environments.

What to monitor

  • Kotlin 1.4 GA date and any last-minute RC fixes that need backports to internal forks. Track JetBrains issue tracker for regressions in kapt, Android incremental compilation, and Kotlin/Native memory model.
  • Performance metrics for build times and runtime benchmarks compared to Kotlin 1.3.72; rollback plans should be documented if RC shows regressions in critical paths.
  • Compatibility status of Gradle plugins (AGP, KSP, Detekt, ktlint) with Kotlin 1.4; outdated plugins can block adoption.
  • Feedback from Android Studio canary channels that bundle the 1.4 plugin—crashes or syntax-highlighting gaps should be escalated before GA.
  • Binary compatibility reports between published artifacts and consumer apps, especially where public APIs are annotated with @OptIn or @RequiresOptIn.

Key takeaways for leads

  • Treat the RC as the staging baseline: align SDKs, internal libraries, and CI images now to avoid a compressed timeline when GA ships.
  • Prioritise DSL-heavy modules and multiplatform libraries for early testing, as they benefit most from the inference and metadata improvements but also pose the greatest compatibility risk.
  • Use explicit API mode as a gradual governance control to stabilize public interfaces before 1.4 GA; document module owners and approval steps for any breaking changes.
  • Capture benchmark deltas and developer feedback to justify adoption to stakeholders who may be wary of upgrading near feature deadlines.
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Kotlin
  • JVM
  • Multiplatform
  • Coroutines
  • Language Tooling
Back to curated briefings