Meeting notes
Actions from last time
Attendees
- Elijah
- Timofey
- Mads
- Marc
- Gregorz
- R. Berkay Bozkurt
Agenda
The Kotlin/Native + SwiftPM PoC
Note: In the end we didn’t talk about it since no SwiftPM folks on the call, however Owen did engage on the thread 
That’s better space for that discussion anyway since not super Java related.
Potential refactor for ffm/jni generators
- Bartek: worked on integer overflow, it was in generators, while most things are the same.
- Small differences in semantics, etc but maybe we can rewrite.
Overall decision: Yes, totally open to cleanups here.
Historically they were entirely separate as we had concerns how different they’ll be; For example initially wanted to do direct calls to Swift functions without the thunks, but either way, it is true that the general “shape” can be shared.
ACTION: Bartek to file an issue and propose some protocol shape we could conform both generators to. We’d like to “drive” them the same way, this simplifies the integration with the CLI etc. Konrad will then review and we can start chipping away on improvements – definitely no “big rewrite” here, just incrementally make room for shared pieces.
Error handling in generator
- Consolidate how we do logging in plugins · Issue #193 · swiftlang/swift-java · GitHub
- ACTION: Bartosz: to make issue about better logging on failure.
- We should provide more understandable errors when we fail to import something, e.g. “this is not supported yet” etc.
- wrap-java has some good messages, you may want to look at those.
- Konrad: we should keep "import as much as you can mode" by default, it is useful default mode because folks use the tool against a large codebase and expect to be able to use as much of it as possible.
- We can offer filtering maybe? Wrap-java offers filter-exclude and filter, we could do the same for jextract.
- Konrad: we should add tests for the failure behaviors.
Runtime testing on Android
Marc: big topic but to start a little bit on it. Chugging along with the SDK, slotted in 6.3 final release, nightlies are released as well etc.
First baby step: testing.
Current state of testing right now is that we support xctest and unit testing on Android... it is done by native swift tests, then scp it into an Android emulator.
Starting to run the testcases, some initial work done in.
- There's no ambient Java env in those.
- To get what working we'd need, build it as an app. This gets into the build topic; we need to build the "tests" into an application... replicate what instrumentation testing is doing or piggy-back on instrumentation testing (easier? what SKIP does; swift-testing is not supported.)
Two topics here:
- The story to getting something packaged "as an app" to get ambient java env
- bridging to java in test-cases
Examples:
- AssetManager in NDK is only availabel when you have a DVM
- Started thinking about how we might do it.
Konrad: Maybe we can start from the gradle plugin?
Marc: Probably good start.
Goal: Java "capable" Swift packages.
Maybe we need to have a SwiftPM plugin to generate a Gradle build that then uses the SwiftJava plugin to build the APK etc.
ACTION: Mads: will turn the jni example app into something we can also runtime test on Android. Will collaborate on that and at least then we verify that SwiftJava runtime bits also work in Android. Good first step.
Gradle plugin development?
-
Timofey: We could rewrite this swift build CLI to then finalize the plugin? At least for SwiftJava purposes...
-
Konrad: Talk with SwiftPM
-
Timofey: Difficult to enforce linkage mode
- Konrad: We’re unsure any of this matters for SwiftJava though, need to look into it.
ACTION: Konrad will review the Plugin PoC and see if we can make it use swift-build instead of xcodebuild. This could be a first step towards plugin.
This also is a pre-requisite for more future Android work, since building APKs etc will likely be done by Gradle, we would not want to reinvent that part.
ACTION: Doug and swift syntax prebuilts 