Swift/Java Interop Community Call #6: April 9th 2026

Development Java interoperability
1

Hi everyone!

This will be our 6th meeting and third one in 2026!

This is a community call intended for anyone interested in joining and collaborating on swift/java interoperability. If you'd like to contribute in any capacity, please don't hesitate to join.

The next meeting I expect we'll want to talk about Gradle integration some more, so please join if you're interested in that!

First Quarter Summary

We're having a really amazing new year with lots of new contributions, thanks a lot to all contributors!

The first quarter was really quite active:

  • 95 commits across 11 full weeks (Jan 5 – Mar 17)
    • 80 came from merged PRs, 15 were direct commits
    • Average: ~7.9 commits/week

And I'd like to shout out @madsodgaard, @Iceman and @Timofey_Solonin for their stream of contributions, thank you!

Key Themes

  1. Generics — Massive updates in making Java generics work correctly in both directions (wrap-java and jextract/jni), largely driven by @Iceman, thanks a lot!
  2. Native collection types — We introduced SwiftDictionaryMap, SwiftSet, Swift tuple support -- those are now fully supported in jextract/jni and don't incur copying onto the JVM heap, unless you want them to
  3. Foundation type bridging — Data, Date, UUID now bridge across JNI. We've also been working hard to avoid linking Foundation by accident, which is a huge win for binary size for our users on Android :robot:
  4. Modularization — swift-java-jni-core split into its own package, allowing some other low-level libraries to reuse some of the core logic. Thank you @marcprux for the support on this front!
  5. Android — We've added some cool features about availability -- we're now able to ingest api-versions.xml and parse java classfiles, resulting in accurate @available(Android ..., *) annotations when importing the Android SDK!

In the coming days we'll also tag a 0.1 of swift-java co you can start relying on it for development rather than depending on the main branch. This isn't API stability yet, but it'll help in adoption in real projects!

Previous meeting

Swift/Java Interop Community Call #5: March 5th 2026

Meeting details

When: 2026-04-09T13:00:00Z (click to see the time in your timezone) [webex]

We found the time to work relatively well and span 4 very different timezones, please cooperate with us as we continue with this timeslot. We may choose different
times in the future.

Where: The meeting will hosted on Webex, make sure to install the app before joining.

7 Likes
Swift Android Native package
2

I posted a follow-up thread on the Swift Android Native package that I mentioned on the call in case folk wanted to discuss it further.

1 Like
3

I did my best taking notes but since I was talking a lot I didn't do the best this time around, would love to ask someone to help taking notes next time maybe :sweat_smile:

Swift Java Community Call Notes: 6

New folks

  • From Cricut
    • Matt Stoker, Andrew Cobb

FishyJoes

Been talking for a while, and now released publicly!

Goal here is to find common way ground with swift-java and try to reuse core infra.

Matt and Andrew introduced the project.

It is a source generator, like swift-java, but based on Sourcery.

It can also bridge to: Kotlin, C#, Typescript, adding Python, wasm.

A little different than swift java because annotation system and builtins
Avoids difficult problems like with protocols etc.

Large userbase, 2 years in production.

Hardware interfacing libraries etc, text libraries, c++ dependencies built through swift. Also targetting wasm.

Fairly mature.

Compiling the library once for whatever system and then those libs call from those languages.

The tool they'd really "prefer to buy" so it's not going to make it a product or whatever, want to work with the community.

Overall consensus is to find ways to collaborate, core swift-java functionality is more advanced than FishyJoe's so it could be leveraged as the core for the existing tools.

Could be a way to offer kotlin or other languabe bindings.

Actions: Matt, Andrew and Konrad to look into potential for reusing functionality.

Gradle plugins and related

Timofey: problem was about understanding packages better. Difficult to understand the build outputs; understanding compiler arguments

Mads: Perhaps we can "--depend-on" Foundation and parse the interface files. Do all the steps as we do today, but automate with a build plugin.

Action: For now goal is to make an GradleJavaPlugin and perhaps GradleAndroidJavaPlugin on top of that. Konrad will set up a very basic Gradle plugin based on Timofey's work, and we can start collaborating on it.

Packaging dependencies

  • Andrew
    • we're focusing on producing an artifact, that contains the jar with all the jars
    • and depend on stdlib jar
    • ACTION: Matt will do an example app and we can learn from their distribution patterns -- in general it is modules as jars and then jars depend on eachother, each bringing their dylib.
  • Cricut has multiple libraries depend on eachother
    • dynamic libraries

Example from cricut, with dependency chain; We will talk about this dependency chain situation more next time