Swift/Java Interop Community Call: November 27th

Development Java interoperability
6

Thanks for the links, I’m aware of these. I was wondering if you had recently worked on some plugin and could share recommended approaches; later I realized we probably should kick off our efforts on top of the existing Swift gradle plugin though :thinking:

The swift-java build and the convention plugins I’m not as much concerned about. Sure, the swift-java build could be cleaned up some more, but that’s not really important – what is important is to make using swift-java easier for developers in their Gradle builds.

The goal here is to offer a “Swift” (or “swift java interop”) plugin for Gradle. We can do this either by building our own, or improving existing ones.

You’ll notice that the Samples including the recent swift-java android sample, have an annoying amount of copy-paste in order to orchestrate invoking the swift build, swift-java tool, and then locate the built dynamic libraries and package them up.

Here’s some rough ideas what such SwiftJava Gradle plugin should be:

Maybe? Invoke swift-java to perform extraction steps:

  • Today we’re relying on swift build triggering swift-java jextract
    • The gradle plugin doesn’t really invoke swift-java, but just does swift-build and we happen to know the Swift project has the swift-java plugin which then triggers jextract.
    • I wonder if it would be beneficial to have the gradle plugin be able to invoke jextract directly?

Building Swift:

  • The plugin “building” a Swift project as part of your gradle build
    • This is for projects which develop swift side by side java, it should be possible to point the plugin at a Package.swift and build either some specific targets, or the whole thing
    • The building remains TBD how much we need to do here… just doing swift build is pretty naive, I’d hope we can do better than that.
  • Preferably, we should take the existing plugin SwiftCompile - Gradle DSL Version 9.2.1 and investigate what’s missing and how we can improve it. I’m told it is not very actively maintained, but perhaps I’m wrong?
    • Then if we can improve and upstream it that would probably be the best, we may need to iterate in a fork for a while to see what we want.
  • We should offer control over building in debug and release modes, and passing flags
    • The existing official plugin has some of that already

SwiftJava tool integrations:

  • I’m not sure if the Gradle plugin should directly invoke swift-java jextract or we leave it to SwiftPM plugins to drive; we should investigate that.
  • Either way, swift-java jextract produces Java sources as outputs; we should make it easy to include those sources in sourceSets of your Gradle build.

Testing

  • Do we want to offer a testSwift task which invokes swift tests of targets the gradle project has included?
    • The existing gradle plugin does so

Improved “depend on Swift library” (maybe?)

  • [future] potentially allow declaring a swift project dependency (this is something you were interested in AFAIK); where we’d declare a package dependency in the gradle build and we’d a) fetch and b) build the dependency as part of the gradle build
    • E.g. if such dependency was already swift-java enabled, via the swift-java SwiftPM plugin, and produced shared libraries, you could then make use
  • Maybe? One might argue to also support “just stuff some Swift sources into src/main/swift but I’m not sure this is great, we’d have to reinvent a Package.swift somewhere anyway… It may be simpler to just keep a “real swift project” side by side.

Support packaging jars (and apks if android specific):

  • Some use cases want to make a “fat” jar with the built shared libraries included in them. This is not trivial for developers not familiar with Swift, because e.g. you need to cross build. When building on macOS you’d want to build for Linux as well (arm, x64 etc), and then allow developers in the gradle plugin to put those together;

So it’s mostly around orchestrating building and packaging Swift libraries into your jars/apks.

I’d welcome any additional opinions and ideas here, cc @android-workgroup, @madsodgaard.

There exists the Building Swift projects Gradle plugin that was developed a few ages ago, however I was told it’s not been very actively maintained.

Most likely it would be best to see if we can improve that plugin, and upstream any changes we might need eventually to the official plugin.

cc @dschaefer2 this plugin should be interesting to your investigations.

@beaumont I think I captured your use case with those points, but if there’s something you’d like to add please do. I think the biggest annoyance for you was building and finding all the shared libraries for other platforms and then producing the far jar, right?

1 Like