Hi everyone,
Given December being a bit chaotic I had to change the day of the week of the sync... I hope most folks would be able to participate, if not, there's always next time in January. Thank you for participating in the Java interop community!
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.
Previous meeting
Meeting notes and follow ups are in the previous call thread:
Event Details
When:2025-12-16T14:00:00Z (click to see the time in your timezone)
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.
Please post your agenda items before hand so we can prepare and/or adjust the time needed.
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!
Hi folks. On the last call, I promised to create issues in SwiftPM regarding integrating SwiftPM dependencies with another build system. Here they are:
I hope these make sense. Perhaps the issue about Objective-C compilations is not as relevant for Swift Java work, but I have a general question: what is the reason Swift Java uses Swift Syntax instead of using the internal Swift compiler APIs directly? From my understanding, Swift Java currently doesn't have a typed understanding of its Swift dependencies. Is there a possibility that in the future it will need to understand the ".swiftmodule" and ".swiftinterface" files similarly to how the Swift compiler understands them?
I believe the linkage issues have more parallels, especially if we consider trying to consume arbitrary SwiftPM dependencies in Gradle JVM compilations and executions.
It was a goal to not “put more other language support stuff” into the Swift compiler. Swift’s C++ interop is deeply embedded in the Swift compiler but that is primarily because of Clang. It was a goal to see if we can pull it off without having to tie the language interop with the specific compiler. If necessary, we can do changes in the compiler to support the interop, but it would be better of those are generally useful features for all kinds of languages, rather than every language hacking in their ad-hoc interop pieces.
In other words: we’re trying to decouple the evolution and features offered by swift-java from being specifically tied to a specific compiler in order to evolve it more quickly and independently. If there are things we’d need the compiler’s help for it is possible to make changes, but if we do, hopefully we’d manifest them as “generally useful” features that many languages could benefit from.
During today's call, I mentioned that SwiftPM can promote transitive products to dynamic libraries. I was only half-correct: xcodebuild does it, and I assumed swift build does it as well, but it instead duplicates machine code. I extracted a reproduction to a sample with some mutable state to illustrate a difference in behavior that produces:
I am wondering whether what swift build does is desirable and expected; the xcodebuild behavior is something I would expect, and I see if you explicitly mark the shared producer’s product as type: .static, xcodebuild complains about:
error: Swift package product 'producer' is linked as a static library by 'executable' and 2 other targets. This will result in duplication of library code.
I assumed swift build does it as well, but it instead duplicates machine code
This has been irksome to us as well (I touch upon it in swift-java/issues/419), which results in Skip having to raise a build warning for Android builds when it detects that multiple dependency paths lead to a product that is not explicitly marked as .dynamic, and causing us to have to make all our libraries dynamic.
I think xcodebuild does the right thing here, and swift build should replicate its behavior.
Just a reminder that we generally don’t talk about the details behind xcodebuild on open source channels. I’ll just say that it is does not necessarily build the exact same way as SwiftPM.
Doug and swift syntax prebuilts 
ACTION: