research: kotlin 2.40

[NickMonrad]

Research: Kotlin 2.4.0 for kernel-ai-assistant

Source: https://blog.jetbrains.com/kotlin/2026/06/kotlin-2-4-0-released/
Current version: Kotlin 2.2.21 → target 2.4.0
Cross-reference: #915 (AGP 9 + Gradle 9 upgrade)
Reviewed by: oracle (see #915 comment)

---

Corrections from Oracle Review

Original claim	Correction
KSP 2.4.0 not released is the primary blocker	Wrong. KSP 2.3.0 decoupled versioning from Kotlin. KSP 2.3.9 can potentially work with Kotlin 2.4.0. Real blocker is AGP: KSP 2.3.9's Gradle plugin needs AGP 9 API surfaces (NoSuchMethodError: AndroidComponentsExtension.addKspConfigurations on AGP 8.x).
AGP 8.7.3 satisfies Kotlin 2.4.0 minimum (8.5.2)	Incomplete. Android's Kotlin support table requires AGP 9.1.0 for Kotlin 2.4. The KGP table (8.5.2) is the general JVM minimum, not the Android effective minimum.
Kotlin 2.4 follow-up is "just version bumps"	Wrong. Must also: remove/revalidate -Xskip-metadata-version-check in 6 modules, ensure AGP 9 built-in Kotlin config is compatible, regression-test KSP/Hilt/Compose. There's a known open KSP regression (google/ksp#2964) with Hilt + Kotlin 2.4 module names.
sourceSets deprecation flagged as relevant	False positive. Repo uses android { sourceSets { } } (AGP API), not the deprecated KotlinAndroidProjectExtension.sourceSets.
AGP 9.2.1 is a safe target	Risky. KGP 2.3.x supports AGP up to 9.0.0; KGP 2.4.0 supports AGP up to 9.1.0. AGP 9.2.x is outside both fully-supported matrices. Target AGP 9.1.1 instead.

---

Actual Compatibility Assessment (corrected)

Component	Current	Required for 2.4.0	Status
Kotlin	2.2.21	2.4.0	—
AGP	8.7.3	≥ 9.1.0 (Android effective minimum)	🔴 Requires #915 first
KSP	2.2.21-2.0.5	2.3.9	✅ (decoupled from Kotlin version)
Gradle	8.11.1	7.6.3–9.5.0 (KGP 2.4.0)	✅ (bump to 9.3.1 in #915)
Hilt	2.58	2.59.2	⚠️ Needs #915 (Hilt 2.59 requires AGP 9)
JVM target	17	any	✅
K1	not used	removed in 2.4.0	✅
Deprecated Compose flags	not used	→ ERROR in 2.4.0	✅
AGP 9 built-in Kotlin	N/A	Must migrate	🔴 #915 must handle

Actual blocker chain: AGP 8.7.3 → must upgrade to AGP 9.1.x first (#915), which requires built-in Kotlin migration (removing org.jetbrains.kotlin.android from 14 modules, migrating kotlinOptions). Only then can Kotlin 2.4.0 be adopted, using KSP 2.3.9 (no need to wait for a KSP 2.4.0 release).

Known risk: google/ksp#2964 — open regression with Hilt code generation under Kotlin 2.4.0's new module-name behavior. Repo's @Provides methods are public (not internal), so the known trigger is not present, but this is an ecosystem risk to monitor.

---

Recommended Strategy (corrected)

Step	Issue	Scope
1	#915	AGP 9.1.1 + Gradle 9.3.1 + Kotlin 2.3.21 + KSP 2.3.9 + Hilt 2.59.2 + built-in Kotlin migration
2	Follow-up PR	Kotlin 2.3.21 → 2.4.0 on AGP 9.1.x baseline, remove -Xskip-metadata-version-check, verify KSP/Hilt/Compose

Why not AGP 9.2.x: KGP 2.4.0's fully supported AGP window is 8.5.2–9.1.0. AGP 9.2.x requires Gradle 9.4.1 and is outside both KGP 2.3.x and 2.4.0 documented support.

Why not bundle Kotlin 2.4 into #915: AGP 9 built-in Kotlin migration alone touches 14 build scripts. Isolate that blast radius from the language upgrade.

---

Features (unchanged from original research)

Stable: context parameters, explicit backing fields, UUID API, .isSorted() checks, no deprecation warnings on imports, annotations in metadata by default, consistent intra-module inlining.

Experimental: collection literals, improved compile-time constants, returnsResultOf() contract, @IntroducedAt, map fallback functions.

Compose Compiler Changes

• StrongSkipping, IntrinsicRemember → ERROR (not used). OptimizeNonSkippingGroups, PausableComposition → deprecated (not used).
• More consistent incremental compilation for internal declarations. Possible artifact size increase from runtime stability inference for cross-file internal types (R8 can eliminate).

Performance Notes

• KSP 2.3.9 fixes a compilation perf regression from 2.3.8
• Hilt 2.59.2 fixes slow incremental-build regression from AGP 9 support
• Kotlin 2.4 Compose: better incremental compilation for internal declarations
• Gradle daemon heap at -Xmx4g should be sufficient; increase if AGP 9/KSP2 OOMs

[lokhor]

Benefit Analysis: Kotlin 2.4.0 for this codebase

Methodology

Searched the entire codebase (~200 Kotlin files) for concrete applicability of each Kotlin 2.4.0 feature. Counted candidate sites, assessed ROI.

---

Context Parameters (Stable) — HIGH VALUE

~75 candidate sites across 3 patterns:

Pattern	Sites	Best example
Hardcoded dispatchers in suspend functions	~50 withContext(Dispatchers.X) calls	RagRepository: 7 methods all wrap in withContext(Dispatchers.IO) — dispatcher is untestable
ViewModel constructor bloat	ChatViewModel (26 params), RagRepository (7), ActionsViewModel (7)	ChatViewModel injects inference engine, repos, voice controllers, skills — all are ambient capabilities every method uses
Composable parameter threading	ChatScreen→ChatContent→InputBar threads 4 voice-related params identically	InputBar has 22 params; ChatContent has 27. Adding a new voice feature means touching 3 files

Concrete win: Replace ChatScreen's voiceCaptureState: VoiceCaptureState, voicePlaybackState: VoicePlaybackState, voiceMode: VoiceMode, mealPlannerActivity: MealPlannerActivity? with implicit context parameters — removes 4 params from 3 composables, makes adding new ambient state a single-file change.

Risk: Requires discipline to not over-use. Context parameters are ambient/implicit — harder to trace than explicit params. Best reserved for truly ambient things (dispatchers, voice state) not business logic dependencies.

---

Explicit Backing Fields (Stable) — LOW VALUE

Found only ~15 simple computed getter properties that would benefit. Examples:

• HardwareProfile.ramLabel — computes from totalRamBytes
• AvailabilitySummary.readyLabel — computes from count fields
• ModelCapabilities.supportsAttachments — boolean computed property

The ~35 MutableStateFlow/SharedFlow backing pairs (e.g., _uiState/uiState) do NOT benefit — they need the mutable reference for emissions. Explicit backing fields are syntactic sugar for get()/set(), not a replacement for the mutable/immutable split pattern.

Verdict: Nice to have, use opportunistically in new code. Not a reason to upgrade.

---

UUID API (Stable) — LOW VALUE

18 sites use java.util.UUID.randomUUID().toString(). Replacement with kotlin.uuid.Uuid.random().toString() saves only the import change. Deeper adoption (changing entity id: String → id: Uuid) would require Room TypeConverters — not worth the churn for 18 sites.

Verdict: Use in new code, don't migrate existing. Not a reason to upgrade.

---

Collection Literals (Experimental) — NOT WORTH IT

~500-600 listOf/mapOf/setOf calls. But:

• Only ~35% are pure literals (candidates for [...] syntax)
• ~25% are variable-only (not candidates)
• Requires @OptIn(ExperimentalStdlibApi::class) at every site (~200 sites across ~100 files)
• Won't be stable until Kotlin 2.5+ (late 2026)

Best candidates: ClockAlertVoiceCommand (19 nested listOf calls) and UnitConversionEvaluator (~20 setOf alias declarations).

Verdict: Skip until stable. Not a reason to upgrade.

---

Other Features — NICHE OR ZERO

Feature	Applicability
.isSorted() / .isSortedBy()	Minor testing convenience. Zero production usage found that would benefit
returnsResultOf() contract	Niche. No custom scope functions found that would use it
@IntroducedAt	Only relevant for published libraries — not applicable
Map fallback functions	Possibly useful. Didn't find obvious nullable-map patterns needing it
Improved compile-time constants	Low. Few const val sites that would benefit from String.lowercase() evaluation
No deprecation warnings on imports	Nice QoL. Currently some LiteRT/MediaPipe transitive deps trigger these

---

Bottom Line

Value tier	Features	Upgrade-worthy?
High	Context parameters (~75 sites)	✅ The one feature that materially improves the codebase
Low	Explicit backing fields, UUID API, .isSortedBy(), import warnings	Nice but not worth the upgrade alone
Zero/negative	Collection literals (experimental, ~200 opt-ins needed), all other experimentals	Wait for stable

The upgrade is worth doing for context parameters alone — but only after #915 (AGP 9) lands, because AGP 9 is the gating dependency. The other features are minor conveniences that don't justify the churn.

Total churn for context parameter adoption: ~75 sites, but can be done incrementally (the feature is additive). Start with the highest-impact sites: ChatScreen composable threading (touches 3 files, removes 4 params) and RagRepository dispatcher injection (touches 1 file, enables TestDispatcher in tests).

[lokhor]

Compose Compatibility Assessment

Compose Compiler Plugin — ✅ No concern

Since Kotlin 2.0.0, the Compose compiler is bundled with the Kotlin plugin. org.jetbrains.kotlin.plugin.compose version = Kotlin version. No separate artifact or version to manage. Upgrading Kotlin to 2.4.0 automatically brings the 2.4.0 Compose compiler.

The standalone androidx.compose.compiler:compiler artifact (last: 1.5.15, Aug 2024) is the deprecated pre-bundling approach — not used.

Deprecated Compose Flags → Errors — ✅ Not affected

These flags become errors in Kotlin 2.4.0 (KT-85343):

• StrongSkipping
• IntrinsicRemember
• enableNonSkippingGroupOptimization
• stabilityConfigurationFile
• generateFunctionKeyMetaClasses

Search confirmed zero usage in this repo. No migration needed.

Compose BOM Minimum Version — ✅ Fine

What	Version
Current Compose BOM	2026.05.00
Latest Compose BOM	2026.05.01 (patch)
Kotlin 2.4.0 release	June 3, 2026

Compose BOM 2026.05.00 was released during Kotlin 2.4.0's RC phase. No minimum BOM version is published for Kotlin 2.4.0, but the release timing suggests no incompatibility. The BOM-to-compiler compatibility window is wide — typically any BOM from the last 12 months works.

Unchecked: April 2026 Compose Blog Post

The April 2026 Compose updates was linked for review but could not be fetched (Google Blogspot CAPTCHA). This post may announce new Compose features that leverage Kotlin 2.4.0 features (e.g., context parameters for @Composable functions). Worth checking manually but unlikely to be a gating concern — new features are additive.

Verdict

Compose version is not a factor in the Kotlin 2.4.0 upgrade decision. The gating dependency chain (AGP 9.1.0 → built-in Kotlin migration → KSP 2.3.9) remains unchanged.

[lokhor]

Update from kotlinlang.org/docs/whatsnew24.html#compose-compiler:

The only Compose compiler changes in 2.4.0:

1. More consistent incremental compilation for internal declarations — stability of internal types across files inferred at runtime. Side effect: possible artifact size increase from dual code-paths (stable + unstable), but R8 full-app optimization eliminates the dead branch. No behavioral change. No action needed.

2. Feature flag deprecations advanced:

   • StrongSkipping, IntrinsicRemember → ERROR (removed in 2.5.0) — not used in this project
   • OptimizeNonSkippingGroups, PausableComposition → DEPRECATED (removed in 2.6.0) — not used in this project

No minimum Compose BOM version is published or required. No Compose runtime API changes. The April 2026 Compose blog post could not be fetched (CAPTCHA), but the official Kotlin 2.4.0 "What's New" page is the authoritative source for Compose compiler changes — and it lists nothing that affects this project.

Reconfirmed: Compose is not a factor in the upgrade decision.