<![CDATA[Soft Art Development]]>https://blog.softartdev.orgRSS for NodeFri, 24 Apr 2026 22:52:30 GMT60<![CDATA[The “Stale Capture” Trap in Jetpack Compose Side Effects (and why it can surprise Kotlin developers)]]>https://blog.softartdev.org/the-stale-capture-trap-in-jetpack-compose-side-effects-and-why-it-can-surprise-kotlin-developershttps://blog.softartdev.org/the-stale-capture-trap-in-jetpack-compose-side-effects-and-why-it-can-surprise-kotlin-developersMon, 26 Jan 2026 02:29:03 GMTSometimes your UI shows the correct value, but a log (or callback) inside LaunchedEffect uses an old one.
This is usually not a Compose “bug”. It is a closure capture issue: a long-running lambda can keep old references.

This article explains the problem with a simple example and shows two safe fixes.

What “stale capture” means

In Kotlin, a lambda can capture variables from the outer scope.
But it does not capture “magic live variables”. It stores references to objects.

So if you capture an object, and later a new object is created, the old lambda will still point to the old object.

This is normal Kotlin behavior.

A simple Compose example

Imagine a screen where:

  • the ViewModel sometimes provides text (for example, after loading from a database)
  • the user edits a text field
  • after a short delay, we run validation and call onValidate(text)

Code (buggy)

@Composable
fun DemoScreen(
    text: String,        // changes over time (ViewModel update)
    onValidate: (String) -> Unit // can also change on recomposition
) {
    // ⚠️ This creates a NEW state object when text changes.
    val textState = remember(text) {
        mutableStateOf(text)
    }

    // We start ONE coroutine for the whole lifetime of this call site.
    LaunchedEffect(Unit) {
        // Some long-running work (timer, polling, etc.)
        delay(2_000)

        // ⚠️ This lambda can use an old reference to textState and/or old onValidate.
        onValidate(textState.value)
    }

    TextField(
        value = textState.value,
        onValueChange = { textState.value = it }
    )
}

What can happen

1) First composition: text = ""
Compose creates textState₁ (object A) and starts the LaunchedEffect.

2) Later: text = "Hello"
Because of remember(text), Compose creates new textState₂ (object B).
The UI now reads object B.

3) After 2 seconds the coroutine finishes delay(...)
The coroutine may still hold object A, so it calls onValidate("") even though the UI shows "Hello".

So UI and side effects can disagree, even if the UI is correct.

Why this happens in LaunchedEffect

LaunchedEffect(key1, key2, ...) starts a coroutine.
That coroutine keeps running until the keys change.

If your effect uses a value but that value is not in the keys, the coroutine may continue running with old references.

That is why Compose has two main patterns:

  • restart the effect when inputs change (use keys)
  • keep the effect running, but read the latest values (rememberUpdatedState)

Fix 1: Restart the effect (add the right keys)

If it is OK to restart the coroutine when input changes, add keys:

LaunchedEffect(text, onValidate) {
    delay(2_000)
    onValidate(textState.value)
}

Now when text changes, the old coroutine is cancelled and a new one starts.

Use this when restarting is cheap and safe.

Fix 2: Keep the effect stable, but read the latest value

If you do not want to restart the coroutine, use rememberUpdatedState.

See the official docs for rememberUpdatedState.

val latestText by rememberUpdatedState(textState.value)
val latestOnValidate by rememberUpdatedState(onValidate)

LaunchedEffect(Unit) {
    delay(2_000)
    latestOnValidate(latestText)
}

Idea: rememberUpdatedState returns a stable holder, and Compose updates its value on recomposition.
So your long-running coroutine keeps the same reference, but it reads the latest value.

Use this when you want one collector, one listener, one timer, etc.

How to “see” the problem (object identity)

On JVM you can print identity to prove that the state object changed:

SideEffect {
    println("textState identity = ${System.identityHashCode(textState)}")
}

When remember(text) recreates the state, the identity will change.

Under the hood (optional)

Compose state is implemented in the runtime. If you want to see a real implementation file, check
SnapshotState.kt in Compose runtime.

You do not need to read it to fix the bug, but it helps to understand that “state” is a real object.

Practical checklist

When you write a long-running side effect (LaunchedEffect, DisposableEffect, timers, listeners, etc.):

1) List what the effect reads (state objects, values, callbacks). 2) For each item, choose:

  • Restart the effect when it changes → put it in the effect keys
  • Do not restart, but need the latest value → use rememberUpdatedState

This simple rule prevents most stale-capture bugs.

References

]]><![CDATA[Kotlin Coroutines on wasmJs: why there is no `runBlocking` (and why “hacks” are risky)]]>https://blog.softartdev.org/kotlin-coroutines-on-wasmjs-why-there-is-no-runblocking-and-why-hacks-are-riskyhttps://blog.softartdev.org/kotlin-coroutines-on-wasmjs-why-there-is-no-runblocking-and-why-hacks-are-riskySat, 03 Jan 2026 15:02:23 GMTCheat sheet
  • runBlocking is a thread-blocking bridge.
  • It exists only for targets that are built from the concurrent source set.
  • js/wasm* are built from jsAndWasm* source sets, so they don’t get runBlocking.
  • On JS (and wasmJs hosted by JS) you cannot block the single event loop and still let async callbacks run.
  • Background reading: Kt. Academy — Coroutines in other languages

1) The build layout makes it explicit

In kotlinx.coroutines, the source set graph is documented directly in kotlinx-coroutines-core/build.gradle.kts:

/* ==========================================================================
  Configure source sets structure for kotlinx-coroutines-core:

     TARGETS                            SOURCE SETS
     ------------------------------------------------------------
     wasmJs \------> jsAndWasmJsShared ----+
     js     /                              |
                                           V
     wasmWasi --------------------> jsAndWasmShared ----------+
                                                              |
                                                              V
     jvm ----------------------------> concurrent -------> common
                                        ^
     ios     \                          |
     macos   | ---> nativeDarwin ---> native ---+
     tvos    |                         ^
     watchos /                         |
                                       |
     linux  \  ---> nativeOther -------+
     mingw  /
 ========================================================================== */

Key point: Targets that support runBlocking share the concurrent source set (jvm, native*). Targets like js, wasmJs, and wasmWasi share jsAndWasm*, where blocking builders are intentionally absent.

2) Where runBlocking actually lives

In concurrent/src/Builders.concurrent.kt it is declared as an expect function:

public expect fun <T> runBlocking(
    context: CoroutineContext = EmptyCoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

Then each “blocking-capable” platform provides its own actual implementation.

Native runBlocking: the essential mechanics

See native/src/Builders.kt (simplified):

val eventLoop: EventLoop? = ...
val newContext: CoroutineContext = ...
val coroutine = BlockingCoroutine<T>(newContext, eventLoop)

coroutine.start(CoroutineStart.DEFAULT, coroutine, block)
return coroutine.joinBlocking()

What matters:

  1. It selects/creates an EventLoop for the blocked thread.
  2. It starts the coroutine.
  3. It blocks the thread in joinBlocking() until completion, while pumping the event loop manually.

3) Minimum about EventLoop (only what we need here)

Blocking builders depend on the ability to process queued work while the thread is blocked.

In common/src/EventLoop.common.kt:

open fun processNextEvent(): Long {
    if (!processUnconfinedEvent()) return Long.MAX_VALUE
    return 0
}

So runBlocking is not just “wait”; it is “wait and keep progressing coroutine work”.

4) Why “blocking” is still possible on Android (even with one UI thread)

Even if you think “my Android app is single-threaded”, it still runs on a real OS thread. That thread can be parked / blocked, and other threads (timers, I/O, Binder, etc.) can still run.

Also, Android’s main thread is built around a message loop (an event loop). The core loop is literally an infinite loop in Looper.loop().

Sources:

Key fragment from Looper.loop():

for (;;) {
    if (!loopOnce(me, ident, thresholdOverride)) {
        return;
    }
}

On Android, “one thread” does not mean “no event loop”. It means: “one thread running an event loop”.

Important: Calling runBlocking on the main/UI thread is still a bad idea. It freezes the Looper, stops message processing, and can lead to ANR (Application Not Responding).

5) Why this cannot exist on wasmJs

On wasmJs (and Kotlin/JS), coroutine resumptions often come from JS callbacks (Promise microtasks, timers, I/O). These callbacks run only when control returns to the JS event loop.

If you block the main thread, you stop the loop, so the coroutine cannot resume.

Minimal JS deadlock example:

function fakeRunBlocking(promise) {
  let done = false;
  promise.then(() => done = true);

  while (!done) {} // blocks the event loop -> then() never runs
}

This is why JS frameworks “wait” by returning a Promise, not by blocking a thread.

6) About “runBlocking for all targets” libraries

There are small community libraries that try to provide runBlocking for JS/WASM. Example: com.javiersc.kotlinx:coroutines-run-blocking-all.

One JS/WASM implementation is found in RunBlocking.kt in run-blocking-kmp (simplified):

public actual fun <T> runBlocking(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T,
): T = GlobalScope.promise(context) { block() } as T

Why this is dangerous

  1. It lies about the return type: Promise<T> is cast to T. This breaks type safety.
  2. It returns immediately: It does not actually wait.
  3. It uses GlobalScope: This breaks structured concurrency (harder cancellation, easier leaks).

7) Your runBlockingAll: better idea, but still not a solution

A simplified version of a common attempt to "fix" this:

actual fun <T> runBlockingAll(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T
): T {
    var out: Result<T>? = null
    val continuation: Continuation<T> = Continuation(context) { out = it }
    block.startCoroutine(receiver = GlobalScope, completion = continuation)
    return out!!.getOrThrow()
}

Why it is a bit better

  • It does not return a Promise disguised as T.
  • If block completes immediately (no suspension), it really returns T.

Why it is not a solution

  • If the coroutine suspends, out is still null, so it crashes on out!!.
  • It still uses GlobalScope.
  • You still can’t “block until resume” on JS/WASM without freezing the event loop.

The verdict:

It can “unwrap” only non-suspending coroutines.
It cannot turn async work into sync work on JS/WASM.

8) Conclusion: don’t overuse runBlocking (even where it exists)

Even on platforms where runBlocking exists (JVM/Android/Native), it should be used rarely.

  • It blocks a thread.
  • On Android, using it on the main/UI thread can freeze the app (no Looper messages → ANR risk).
  • It makes code harder to maintain and easier to deadlock.

In app code, prefer launching coroutines from a proper scope:

  • Android UI layer: use lifecycle scopes like viewModelScope.
  • Lower layers / non-Android: create your own scope and control its lifetime. For example:
val scope = CoroutineScope(
    SupervisorJob() + Dispatchers.Default + coroutineExceptionHandler
)

The best long-term strategy is to avoid runBlocking in your business logic. If you later port your app/library to more platforms (especially web / wasmJs), you will have much less work, because you won’t need to migrate blocking calls to suspend and async flows.

]]><![CDATA[Under the Hood: How Compose Multiplatform Opens a URL]]>https://blog.softartdev.org/under-the-hood-how-compose-multiplatform-opens-a-urlhttps://blog.softartdev.org/under-the-hood-how-compose-multiplatform-opens-a-urlTue, 23 Dec 2025 09:47:30 GMTAs mobile developers moving into the Multiplatform space, we often take high-level APIs for granted. A perfect example is opening a hyperlink. In Jetpack Compose, we simply grab the LocalUriHandler and call openUri(). But what happens after that call? How does a single line of Kotlin code trigger the default browser on Android, iOS, Windows, macOS, and Linux?

Today, we are diving deep into the call stack—from the Compose API down to the C++ JNI calls in the JDK.

For example, UriHandler is used like this (Kotlin Multiplatform RSS Reader sample):

val uriHandler = LocalUriHandler.current
// ... some code omitted
uriHandler.openUri(url)

This allows opening a link in an external browser on Android, iOS, Desktop (Java/AWT) and Web (wasmJs).

Compose API

UriHandler interface (AndroidX source code):

interface UriHandler {
    fun openUri(uri: String)
}

Android implementation (AndroidUriHandler):

class AndroidUriHandler(private val context: Context) : UriHandler {
    override fun openUri(uri: String) {
        try {
            context.startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(uri)))
        } catch (e: ActivityNotFoundException) {
            throw IllegalArgumentException("Can't open $uri.", e)
        }
    }
}

Desktop / iOS / Web (Skiko-based)

Next, Compose delegates to a Skiko-based implementation (PlatformUriHandler):

internal class PlatformUriHandler : UriHandler, URIManager()

URIManager and URIHandler_openUri are defined in Skiko:

open class URIManager {
    open fun openUri(uri: String) = URIHandler_openUri(uri)
}
internal expect fun URIHandler_openUri(uri: String)

Skiko platform actuals

Desktop (AWT / Java):

// excerpt
val desktop = Desktop.getDesktop()
if (desktop.isSupported(Desktop.Action.BROWSE)) {
    desktop.browse(URI(uri))
    return
}
// Linux fallback: Runtime.getRuntime().exec(arrayOf("xdg-open", URI(uri).toString()))

macOS (Kotlin/Native):

internal actual fun URIHandler_openUri(uri: String) {
    NSWorkspace.sharedWorkspace.openURL(NSURL.URLWithString(uri)!!)
}

Web (wasmJs):

internal actual fun URIHandler_openUri(uri: String) {
    window.open(uri, target = "_blank")
}

iOS (UIKit):

internal actual fun URIHandler_openUri(uri: String) {
    UIApplication.sharedApplication.openURL(
        url = URLWithString(uri)!!,
        options = emptyMap<Any?, Any>(),
        completionHandler = null
    )
}

What java.awt.Desktop.browse() actually does (OpenJDK)

Next: what java.awt.Desktop.browse() (AWT, not Compose) actually does, and how it opens the browser on different OSes.

High-level flow

In java.awt.Desktop, browse() does a few checks and delegates to the platform peer:

public void browse(URI uri) throws IOException {
    checkAWTPermission();
    checkExec();
    checkActionSupport(Action.BROWSE);
    Objects.requireNonNull(uri);
    peer.browse(uri);
}

The peer comes from SunToolkit.createDesktopPeer(this) inside the private constructor:

private Desktop() {
    Toolkit defaultToolkit = Toolkit.getDefaultToolkit();
    // same cast as in isDesktopSupported()
    if (defaultToolkit instanceof SunToolkit) {
        peer = ((SunToolkit) defaultToolkit).createDesktopPeer(this);
    }
}

Sources:

Files:

Windows

On Windows, the peer is sun.awt.windows.WDesktopPeer. It calls a native ShellExecute(...) wrapper:

@Override
public void browse(URI uri) throws IOException {
    this.ShellExecute(uri, ACTION_OPEN_VERB);
}

private void ShellExecute(URI uri, String verb) throws IOException {
    String errmsg = ShellExecute(uri.toString(), verb);

    if (errmsg != null) {
        throw new IOException("Failed to " + verb + " " + uri
                + ". Error message: " + errmsg);
    }
}

private static native String ShellExecute(String fileOrUri, String verb);

Native side uses Windows ShellExecute (after COM init):

JNIEXPORT jstring JNICALL Java_sun_awt_windows_WDesktopPeer_ShellExecute
  (JNIEnv *env, jclass cls, jstring fileOrUri_j, jstring verb_j)
{
    ...
    HRESULT hr = ::CoInitializeEx(NULL, COINIT_APARTMENTTHREADED |
                                        COINIT_DISABLE_OLE1DDE);
    HINSTANCE retval;
    DWORD error;
    if (SUCCEEDED(hr)) {
        retval = ::ShellExecute(NULL, verb_c, fileOrUri_c, NULL, NULL,
                                SW_SHOWNORMAL);
        error = ::GetLastError();
        ::CoUninitialize();
    }
    ...
}

Files:

macOS

On macOS, the peer is sun.lwawt.macosx.CDesktopPeer. browse() delegates to lsOpen(uri) which calls native _lsOpenURI(...):

@Override
public void browse(URI uri) throws IOException {
    this.lsOpen(uri);
}

private void lsOpen(URI uri) throws IOException {
    int status = _lsOpenURI(uri.toString());

    if (status != 0 /* noErr */) {
        throw new IOException("Failed to mail or browse " + uri + ". Error code: " + status);
    }
}

private static native int _lsOpenURI(String uri);

Native side uses LaunchServices (LSOpenURLsWithRole):

JNIEXPORT jint JNICALL Java_sun_lwawt_macosx_CDesktopPeer__1lsOpenURI
(JNIEnv *env, jclass clz, jstring uri)
{
    OSStatus status = noErr;
JNI_COCOA_ENTER(env);

    // So we use LaunchServices directly.
    NSURL *url = [NSURL URLWithString:JavaStringToNSString(env, uri)];

    LSLaunchFlags flags = kLSLaunchDefaults;
    LSApplicationParameters params = {0, flags, NULL, NULL, NULL, NULL, NULL};
    status = LSOpenURLsWithRole((CFArrayRef)[NSArray arrayWithObject:url],
                                kLSRolesAll, NULL, &params, NULL, 0);

JNI_COCOA_EXIT(env);
    return status;
}

Files:

Linux / X11 (Unix)

On Linux/X11, the peer is sun.awt.X11.XDesktopPeer. Java delegates to a native gnome_url_show(...):

public void browse(URI uri) throws IOException {
    launch(uri);
}

private void launch(URI uri) throws IOException {
    byte[] uriByteArray = ( uri.toString() + '\0' ).getBytes();
    boolean result = false;
    XToolkit.awtLock();
    try {
        if (!nativeLibraryLoaded) {
            throw new IOException("Failed to load native libraries.");
        }
        result = gnome_url_show(uriByteArray);
    } finally {
        XToolkit.awtUnlock();
    }
    if (!result) {
        throw new IOException("Failed to show URI:" + uri);
    }
}

private native boolean gnome_url_show(byte[] url);
private static native boolean init(int gtkVersion, boolean verbose);

Native side tries GTK first (gtk_show_uri), then GNOME (gnome_url_show):

JNIEXPORT jboolean JNICALL Java_sun_awt_X11_XDesktopPeer_init
  (JNIEnv *env, jclass cls, jint version, jboolean verbose)
{
    if (gtk_has_been_loaded || gnome_has_been_loaded) {
        return JNI_TRUE;
    }

    if (gtk_load(env, version, verbose) && gtk->show_uri_load(env)) {
        gtk_has_been_loaded = TRUE;
        return JNI_TRUE;
    } else if (gnome_load()) {
        gnome_has_been_loaded = TRUE;
        return JNI_TRUE;
    }

...

JNIEXPORT jboolean JNICALL Java_sun_awt_X11_XDesktopPeer_gnome_1url_1show
  (JNIEnv *env, jobject obj, jbyteArray url_j)
{
    ...
    if (gtk_has_been_loaded) {
        gtk->gdk_threads_enter();
        success = gtk->gtk_show_uri(NULL, url_c, GDK_CURRENT_TIME, NULL);
        gtk->gdk_threads_leave();
    } else if (gnome_has_been_loaded) {
        success = (*gnome_url_show)(url_c, NULL);
    }
    ...
}

Files:

Other platforms

In OpenJDK, desktop support is primarily implemented for Windows, macOS, and Unix/X11. On headless/minimal builds (or when native libraries are missing), Desktop may report that BROWSE is unsupported and throw UnsupportedOperationException / IOException instead of opening a browser.

Summary

When you write uriHandler.openUri("https://hashnode.com/") in your common Compose code, you are triggering a massive chain of abstractions:

  1. Compose: LocalUriHandler delegates to platform implementation.

  2. Skiko: Delegates to java.awt.Desktop (on JVM).

  3. AWT: Delegates to OS-specific Peers (WDesktopPeer, CDesktopPeer, XDesktopPeer).

  4. JNI: Crosses the boundary into C/C++/Objective-C.

  5. OS API: Finally calls ShellExecute, LSOpenURLsWithRole, or gtk_show_uri.

It is a long journey for a simple click, but it highlights the power of Kotlin Multiplatform: writing once, and letting the framework handle the system-level complexity.

]]>