[piercifani]

Stack 18/21 · base: jni/17-closure-results · previous: #21 · next: #23 (jni/19-enum-swift-case-names)

Problem

An async closure parameter got a synchronous Java interface, void apply(Item). Swift called it and went on without waiting for the Java side, so Java couldn't do asynchronous work for an async closure. Kotlin couldn't either: a coroutine, or a CompletableFuture, returned from the lambda was ignored.

Changes

An async closure's functional interface returns CompletableFuture<T>, with T boxed and Void for no result:

public interface work {
  CompletableFuture<Void> apply(Item _0);
}

The Swift closure calls it and awaits the future with _awaitCompletableFuture, from #7. That resumes the task when the future completes instead of blocking a thread. It's the same mechanism as an async requirement of a Java-implemented protocol:

• The call: apply is called dynamically, because wrap-java doesn't bind a generic CompletableFuture<T> result.
• The result: its value is converted on the thread the task resumed on.
• Failures: a failed future throws the Java exception in a throwing closure. In a non-throwing closure it traps, as a non-throwing protocol requirement does.
• Result types: Void, types translated directly (primitives, String) and jextracted types.
• What's excluded:
  • Async closures never use the non-escaping lowering or a JDK functional interface. (Int64) async -> Int64 isn't a LongUnaryOperator.
  • They need the default completableFuture async mode and are skipped in legacyFuture mode, since a Future can't tell Swift it completed.

Relation to swiftlang#913

Upstream swiftlang#913 gives async closures the same Java API. This PR implements it separately, on top of this stack:

• Waiting: jextract/jni: Support async closures (#834) swiftlang/swift-java#913 calls future.get(), which blocks the Swift task's thread until Java completes. This PR awaits without blocking, with the continuation from JNI: Java implementations of async and cross-module Swift protocols #7.
• Code reuse: it reuses this stack's escaping-closure lowering (JNI: escaping closures taking jextracted types; @Sendable/@MainActor closure types #2) and Java-implemented protocol support (JNI: Java implementations of async and cross-module Swift protocols #7).

When swiftlang#913 lands upstream, the two need reconciling.

Kotlin in this PR

ClosuresTest.kt with Closures.swift:

// public func perform(id: String, _ work: @escaping @Sendable (Item) async -> Void) async
Notifier.init().perform("z") { item ->
    GlobalScope.future<Void?>(Dispatchers.Default) {   // a coroutine, as a CompletableFuture
        delay(50)
        seen += item.id
        null
    }
}.await()
assertEquals(listOf("z"), seen.toList())   // Swift waited for the coroutine

Why Skip needs it

Skip bridges async Swift closures to Kotlin suspend functions, so a Kotlin implementation can suspend and Swift waits for it.

Testing

• Kotlin sample: ./gradlew :Samples:SwiftJavaExtractJNIKotlinSampleApp:test passes (46 tests).
• New JNIAsyncClosureTests (4 tests):
  • the Java interfaces return futures (also for a non-escaping primitive closure);
  • the Swift closure awaits the future;
  • a throwing closure propagates the Java failure;
  • legacyFuture mode skips them.
• JNI sample: AsyncClosuresTest checks four cases:
  • Swift waits for a delayed Void future;
  • a non-escaping primitive closure;
  • a struct result;
  • a failed future surfacing as the Swift call's exception.
• Full swift test --disable-experimental-prebuilts --disable-sandbox (686 tests), ./gradlew :Samples:SwiftJavaExtractJNISampleApp:test (302 tests) and ./gradlew :SwiftKitCore:test pass.
• swift format format leaves changed files unchanged; swift format lint --strict; git diff --check.

Not in this PR

• Async closures returned to Java (JNI: closures returned to Java, and optional closure parameters #21 skips them).
• Optionals, arrays and other results of async closures beyond those listed.
• FFM mode.

🤖 Generated with Claude Code