[piercifani]

Stack 24/24 · base: jni/23-foundation-java-types · previous: #27

Problem

#21 lets Java read a closure back from Swift, such as the getter of a closure property, as a Java lambda over a SwiftClosure handle. Java calls that lambda synchronously and from any thread, so closures that can't be called that way were skipped:

• @MainActor closures;
• async closures;
• throws closures.

These are exactly the callbacks a view model hands its UI: var onTap: @MainActor () -> Void, var onSelect: @MainActor (Item) -> Void, var save: @MainActor (String) async throws -> Void.

Changes

• @MainActor closures go through a new _makeMainActorSwiftClosure, which calls them under MainActor.assumeIsolated. Java has to call them on the main thread, as Compose calls a view model's callbacks. Any other thread traps, the same rule as calling a @MainActor function from Java (Samples: Swift 6 JNI sample used from Kotlin, with main-actor view models (on swiftlang#938) #11).
• async closures, main-actor isolated or not, throwing or not, return a CompletableFuture. That's what their Java interface already declares for closures Java implements (JNI: async closures implemented in Java return a CompletableFuture #22). A new _swiftClosureFuture:
  • converts the arguments on the calling thread;
  • awaits the closure in a task, which hops to the main actor when the closure is isolated to it;
  • completes the future with the boxed result, or with the error as a Throwable (JNI: Swift Error values cross as Java Throwables #25).
• Synchronous throws closures are still skipped. A synchronous Java call has no way to receive the error.

Not included: cancelling the returned future doesn't cancel the task, unlike async functions (#10).

Kotlin in this PR

ScreenCallbacksTest.kt with ScreenCallbacks.swift:

val screen = ScreenModel.init()                 // @MainActor final class
screen.onTap.apply()                            // var onTap: @MainActor () -> Void
screen.onSelect.apply("BTC")                    // var onSelect: @MainActor (String) -> Void
assertEquals("Markets", screen.title.apply())   // var title: @MainActor () -> String
screen.onDismiss?.apply()                       // var onDismiss: (@MainActor () -> Void)?

assertEquals(3L, screen.count.apply("abc").get())   // var count: @Sendable (String) async -> Int64
val failed = screen.save.apply("")                   // var save: @MainActor (String) async throws -> Void
assertIs<ScreenError>(assertFailsWith<ExecutionException> { failed.get() }.cause)

Why Skip needs it

Getters of closure properties were the largest remaining cause of skipped declarations in a production Skip Fuse app (9 Skip modules) run through this stack: 420 of 930, 405 of them in its view-model module. Compose calls these callbacks from the UI thread.

Testing

• Kotlin sample: ./gradlew :Samples:SwiftJavaExtractJNIKotlinSampleApp:test passes (56 tests, including 2 in ScreenCallbacksTest).
• JNIClosureResultsTests: the @MainActor and async throws closure thunks. A synchronous throwing closure is still skipped; that test replaces the one asserting @MainActor closures were skipped.
• swift test passes.

🤖 Generated with Claude Code