Swift/Java interoperability tools and libraries(twitter.com) |
Swift/Java interoperability tools and libraries(twitter.com) |
- https://github.com/swiftlang/swift-java
- https://forums.swift.org/t/improving-swift-support-and-inter...
Objective-C was actually embraced by the community, only Java heads cared about the bridge, and it was eventually killed.
I feel it was a lost opportunity, but what do I know.
Hopefully JavaKit can find their usefulness too!
I guess Swift has a lot less run-time dynamism going on, so it may not be too hard to translate Swift semantics to Java. Definitely interested to see how this unfolds over the next year.
[1] https://developer.apple.com/library/archive/documentation/Co...
It uses Swift macros to add a `JavaObjectHolder` property to Swift types annotated with `@JavaClass`[0]. `JavaObjectHolder` is a Swift class that takes a global JNI reference to the Java object, and releases it when the holder is destroyed[1].
The result is that a codegen utility emits Swift structs[2] that wrap the JNI values, and the JNI glue code for method invocation is applied at compile-time when the macros are expanded.
[0] https://github.com/swiftlang/swift-java/blob/e7d7a217e37d49b...
[1] https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...
[2] https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...
Which ironically would be just like Flutter, totally bypassing any native UI.
My gut feeling is both teams probably have a plan for steamrollering the other in the event of anti monopoly measures forcing each to accept the other store. I.e. it is conceivable you could launch the Play Store on iOS and run a significant proportion of Android apps through a compat layer.
Anyone that cares about performance on Android has to write the userspace logic directly in Java or Kotlin, and use Android IPC instead of JNI.
Kotlin is growing in all areas, especially backend (being fully embraced by Spring/Spring Boot et al).