I'm happy to announce we're going to try out a "community call", similar to what workgroups are doing but more casual. Myself and @madsodgaard who has been working on jextract in JNI mode during Summer of Code will be present in the call, and we welcome anyone interested in the topic. The intent is also to have some folks interested on the Android side of things represented.
The primary purpose of these calls is to coordinate work and collaborate on developing Java interoperability (swift-java), including any support tools like gradle or swiftpm plugins etc. If you'd like to contribute in any capacity, please don't hesitate to join.
We intend to keep this meeting going on a regular basis, and may adjust its time depending on members joining.
Given my initial scan of potentially interested folks, it seems we're EU (and JST) heavy, with some potential PST folks. While it is hard to have an ideal time for all timezones, this should serve as a good start given the geography of members. I'm more than happy to host additional community call that may be easier for other timezones.
Where: The meeting will hosted on Webex, make sure to install the app before joining.
Agenda
The agenda is pretty open and we'd like to hear about your use cases, success stories, problems, or ideas.
While this isn't an official workgroup meeting per se, we'd like to keep it focused on development tasks: how to improve, coordinate, or plan the future development of swift java interoperability. If you have experience, or are interested in gaining experience, developing language interop, this is the place to be!
I've chatted with more folks interested in joining these calls, and in order to accommodate more people joining we're moving the call to:
Changed meeting time:
November 6, 2025 at 15:00, CET / November 6, 2025 at 14:00, London / November 6, 2025 at 6:00, Cupertino / Nov 6, 2025 at 23:00, JST / view in your timezone.
Meeting notes from the first Swift/Java interoperability call.
Swift Java Community Call Notes
Konrad
Mads
Thomas
Greg
Joannis
Marc
Finagolfin*
Agenda:
Swift Java “JNI only” Package status -- Marc
Konrad: Working through it, following swiftlang repo creation process, should hopefully have it done soon
Android & JNIOnLoad fun? -- Mads
28 ang below we could load libart etc.
above 30? there's official api access
Mads: would be good to not have different strategies for every platform
Preferred: OnLoad and store the vm ref
calling the createJVM probably we don't care about
We wait on swift-java-jni probably
concerned about linking
We currently static link swift-java lib;
Official way is the JNIOnLoad on load time of the lib
Marc: only problem is that its not transitively called
The "get jvms" API does not work on 29, and 30; so we can't use that
Standard way in SKIP: manually call during app startup, call into a native function and hang onto jvm from there
ACTION: Wait till we do swift-java-jni, then cooperate on something that should serve most if not all use-cases nicel
How can we contribute, is there some guide about patterns to follow? -- Greg
Focus on interop API; say we wanted to contribute nonescaping closures etc.
Architecturally explain maybe explain some more.
ACTION: Konrad to write up some architectural hints to help "how to contribite", mark some issues as “good first issue”
(Old) Android example issues -- Thomas
Sounds like this was about Mads’ old example; the new example should be easier to follow, but please file issues or PR if something’s off about it still.
Had some issues with the android swift-java example
Android SDK 6.2 release mixup in SDKs perhaps caused issues?
Mads: This sounds like the old example, that is expected
Mads: how do we package things, i.e. do we static link "single big project with all dependencies"
We need a way to express where our dependencies are for jextract for this
Marc: everything in SKIP is forced to be dynamic linked; The static linking in theory is interesting
However in practice the static linking if two libs do that that's bad.
Currently SKIP mandate all dependencies
Currently: SwiftPM has no way to force "all static"
Should we do a feature to "force dynamic libs in this build"
Not all dependencies CAN be static linked so this is a safer bet; more general
There's problems about version clashes like if multiple dependencies do depend on sqlite etc.
e.g. GRDB has top level packages because GRDB-dynamic
ACTION: Konrad, make an issue about the linking discussion
ACTION: Greg, some quick update to the android example how to add dependencies
Status updates:
Mads:
jextract+jni: async funcs are now imported as CompletableFutures (API 24)
jextract+jni: working on nested types in Swift
jextract+jni: implementing Java "interfaces" as protocols using Swift type
Konrad:
Working on calling Java funcs from Swift and automatic import of Java APIs (wrap-java)
Please try things out and report issues for things that don’t work
Gradle plugins / building:
Konrad: Discussion about building -linux-arm64-6.2.1.jar etc, vs REALLY fat jars etc
Really use-case dependent, some people want one or the other; a Gradle plugin could simplify this a bit, because it’s really tricky to get right at first.
Marc: Skip builds
AAR, every swift build takes the .so files and bindings and THEN the AARs are put together into an APK
ABI compatibility discussion
Lack of ABI kinda troublesome adoption because matching Swift versions would lead to “everyone rebuild for new Swift version”, however short term this may be managable;
This is kind of new with the arrival of swift-java and jars which contain binary compiled Swift; Server projects didn’t really encounter this up until now.
Next call
We will schedule another call in 2 weeks time, I will share a meeting link and exact date in a new forums thread.
