Rob D

Posted on Oct 1 • Originally published at robd.tech

The Cost of Concurrency Interop: Trading Clean Modularity for Shared JVM Efficiency

#architecture #java #kotlin

“I pushed the boundaries of Kotlin/Java interop in the same JVM. The result? Technically perfect, but architecturally rigid. Even with a clean stub, direct coupling across subsystems is a maintenance burden, but when the goal is to keep two APIs on different platforms in lockstep, that coupling becomes a powerful diagnostic tool.”

Summary

This article uses a Kotlin/Java interop demo as a lens on software architecture — showing how shared runtimes blur boundaries, invite circular dependencies, and turn temporary bridges into long-term traps if left unchecked. It’s a study in deliberate coupling, and why even flawless interop carries structural cost.

1. Why I Built It

When I released JCoroutines (for Java) and ABCoroutines (for Kotlin), both libraries implemented structured concurrency: cancellation, timeouts, and lifecycle scoping, but each expressed it in their own idiomatic way.

Proving that they behaved identically under load was crucial. It wasn’t enough for the APIs to look similar; they had to propagate cancellation, timing, and errors the same way across complex hierarchies.

That meant building something most developers would never attempt:

Running two structured-concurrency engines inside the same JVM and verifying they behave as one.

The result was abcoroutines-jcoroutines-interop, which is a lightweight bridge layer that allows Java and Kotlin structured coroutines to cooperate in one runtime, sharing virtual threads, tokens, and scopes.

It worked; exactly as intended.
But it revealed a truth every system designer eventually meets:

Shared efficiency comes at the cost of modular clarity.

2. The Bridge:

A Custom Interface Layer
To align Kotlin’s suspend model with Java’s explicit SuspendContext, I created a custom interface layer that translated one runtime’s entry points into the other’s expectations.

At the heart of this layer were functional adapters, my minimal wrappers that allowed a Kotlin coroutine block to appear as a Java callable, or vice versa.

// Expose a suspend block as a Java UnaryFunction
fun <T> exposeAsJava(block: suspend () -> T): UnaryFunction<Unit, T> =
    UnaryFunction { runBlocking { block() } }

These adapters were mechanically simple but semantically deep: they ensured parity across both systems without reflection or hidden threading.

However, they were not domain APIs.
They were coupling mechanisms; tools to align runtime semantics for validation.

✅ Technically sound.
⚠️ Architecturally non-standard.
🎯 Intentionally built that way.

3. Example:

Kotlin Authoring a Java-Style Coroutine
One of the most instructive interop tests involved Kotlin acting in Java’s concurrency dialect, this involved writing and executing a JCoroutines-style function within Kotlin’s test harness.

val javaFunction = { ctx: SuspendContext ->
    // Capture cancellation token for parity assertions
    tokenRef.set(ctx.cancellationToken)

    // Signal readiness as soon as entry occurs
    if (!ready.isCompleted) ready.complete(Unit)

    // Return immediately — the Java coroutine pattern
    "started"
}

// Convert the Java-style block into a Kotlin suspend function
val kotlinSuspend = ExposeAsKotlin.blocking(javaFunction)

// ExposeAsKotlin only builds the wrapper — it doesn't run it
val result = runBlocking { kotlinSuspend() }
Here Kotlin is authoring, not just invoking, a Java coroutine.

The function signature (SuspendContext) -> String is JCoroutines, not idiomatic Kotlin.
ExposeAsKotlin.blocking(...) constructs a suspendable wrapper that mirrors Java semantics.
runBlocking executes it inside a structured scope, verifying identical behavior.
🧠 In this moment, Kotlin isn’t just interoperating with Java — it’s authoring a Java coroutine, acting within the same structured runtime contract.

The code is not just language interop.
Its copying behaviour exactly: Kotlin reproducing Java’s concurrency semantics inside its own runtime.

4. Controlled Coupling and Its Consequences

From a testing perspective, this layer was invaluable:

✅ Semantic parity: cancellation, timeout, and scope propagation matched exactly.
✅ Incremental migration: Java code could be ported piece-by-piece to Kotlin.
✅ Deterministic equivalence: identical scenarios could be executed from either side.
But the interop is more than a test harness, it’s also a transition mechanism.

By using adapters like ExposeAsKotlin, developers can progressively port JCoroutines-based Java components into native Kotlin coroutines without lock-in or behavior drift.

It acts as scaffolding during a rewrite:

Each Java coroutine can be mirrored as a Kotlin suspend function.
Existing structured tests remain valid.
Parity is guaranteed before full migration.
The crucial caveat:

🧩 ExposeAsKotlin creates the bridge! You choose when and where to run it.*
It’s a bridge, not a runtime.

That makes it an excellent transition mechanism, it is scaffolding that enables a safe cross-language rewrite, but not something to leave in place long term.

Architecturally, it remains intentionally inappropriate for production:

⚠️ Collapses subsystem boundaries through shared runtime state.
⚠️ Blurs ownership of execution context and cancellation.
⚠️ Introduces implicit lifecycle coupling that will age poorly.
🔁 Invites circular dependencies if both sides begin calling through each other’s adapters — turning the bridge into a feedback loop.
These cycles compile cleanly but break modular isolation, making initialization order unpredictable and long-term refactoring costly.
I didn’t stumble into a bad boundary! I crossed it consciously, to measure the cost and prove equivalence.

This kind of coupling is brilliant for diagnosis and migration, but fragile for long-term architecture.

5. When Breaking the Rules Is Worth It

Every well-layered system hides constraints.
Sometimes you must break them; deliberately, to understand where the real pressure lies.

By letting Kotlin behave as Java, I confirmed both libraries obey the same structured-concurrency laws.
By coupling them, I saw exactly why such coupling should not persist.

⚖️ Insight often comes from temporary impurity.

The challenge is discipline: recognising that a bridge is a learning device, not a foundation.

6. Lessons Learned

✅ Deliberate coupling is acceptable in research; remove it before release.
⚙️ Custom stubs belong to validation, not to API design.
🧩 ExposeAsKotlin is powerful for migration, but it is dangerous for integration.
🧠 Architectural maturity means knowing when a shortcut is a scaffold.
🔁 Avoid circular awareness. Once both languages depend on each other’s adapters, the boundary you meant to observe is gone.
Clean architecture isn’t about perfection, it’s about intentional imperfection in service of understanding.

7. Closing Reflection

The JCoroutines ⇄ ABCoroutines Interop demonstrated that two structured-concurrency frameworks can coexist cleanly on one JVM.
But it also shows a universal lesson:

Shared efficiency costs modular independence.
Every temporary bridge needs a demolition plan.

So yes! The interop works flawlessly.
It proves parity, supports migration, and validates design.
But its highest purpose is to disappear once its job is done.

Clean architecture isn’t about never crossing boundaries. The important cnsiderations are about knowing why you did, what you learned, and when to dismantle the bridge.

And while every example here is written in Kotlin, the lesson is universal.
The same architectural pressures exist in Java, or any language where runtime sharing tempts you to trade boundaries for convenience.
The syntax changes; the principles don’t.

📘

DEV Community