4 ms·

Swift/Java interoperability tools and libraries

83 points by timsneath 2y ago

microflash 2y ago
This sounds useful. Here are links that actually load on my phone. - https://github.com/swiftlang/swift-java https://github.com/swiftlang/swift-java - https://forums.swift.org/t/improving-swift-support-and-interoperability-experience-for-android/71470 https://forums.swift.org/t/improving-swift-support-and-inter...
aaronbrethorst 2y ago
Plus ça change: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf https://developer.apple.com/library/archive/documentation/Co...
- pjmlp 2y ago
  The reasoning being different though, back then Apple wasn't sure Objective-C would take off among Mac OS developer crowd, used to Object Pascal and C++, Java support and its high integration with OS APIs was a kind of Plan B. 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.
liuliu 2y ago
PythonKit (from Swift) is underrated but immensely useful in certain scenarios (i.e.: https://engineering.drawthings.ai/from-iphone-ipad-to-mac-enabling-rapid-local-deployment-of-sd3-medium-with-s4nnc-324bd5e81cd5 https://engineering.drawthings.ai/from-iphone-ipad-to-mac-en...). Hopefully JavaKit can find their usefulness too!
wiseowise 2y ago
Will be wildly ironic if Apple pulls uno reverse card and eats Kotlin on Android instead of the other way around.
- airstrike 2y ago
  It will also be glorious
- pjmlp 2y ago
  Except contrary to iOS, on Android the C and C++ surface is very small, and calling JNI is a huge performance bottleneck. 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.
- Alupis 2y ago
  Outside of Apple's ecosystem, is anyone using Swift? Kotlin is growing in all areas, especially backend (being fully embraced by Spring/Spring Boot et al).
  - pjmlp 2y ago
    Spring embraces all JVM languages that can bring them new customers.
    - Alupis 2y ago
      They have gone hard on Kotlin. Very hard. For example, in all of Spring/Boot's documentation, you will find Java and Kotlin examples, but not other JVM languages.
      - wiseowise 2y ago
        Because they’re most likely commercial partners with JetBrains.
      - pjmlp 2y ago
        I am old enough to remember when Groovy had similar treatment by Spring.
- daghamm 2y ago
  Kotlin-Java interoperability is at a completely different level.
glhaynes 2y ago
Cool! One thing Swift is really (maybe uniquely?) strong at is C/C++/Objective-C interop, including mixing "legacy" code with Swift and even replacing it file-by-file with minimal ceremony. Looks like this is aiming to bring a similar level of interop to Swift<->Java.
koito17 2y ago
This gives me flashbacks to the Objective-C / Java bridge [1] from over a decade ago. It makes me wonder how they are dealing with memory management when Java objects are being used from Swift (or Swift objects from Java). This was one (of various) issues that made using the Cocoa Java bridge a bit unpleasant. 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/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf https://developer.apple.com/library/archive/documentation/Co...
- lukeh 2y ago
  IIRC, the ObjC/Java bridge was first done at NeXT for WebObjects around 1996... almost thirty years ago!
- favorited 2y ago
  > It makes me wonder how they are dealing with memory management when Java objects are being used from Swift 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/e7d7a217e37d49b326b3367e8299fedcd54cabe2/Sources/JavaKitMacros/JavaClassMacro.swift#L67 https://github.com/swiftlang/swift-java/blob/e7d7a217e37d49b... [1] https://github.com/swiftlang/swift-java/blob/main/Sources/JavaKit/JavaObjectHolder.swift https://github.com/swiftlang/swift-java/blob/main/Sources/Ja... [2] https://github.com/swiftlang/swift-java/blob/main/Sources/JavaKitNetwork/generated/URI.swift https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...
renewedrebecca 2y ago
Oh, well that’s cool!
trigganiggaz 2y ago
[flagged]

83 points by timsneath 2y ago

This sounds useful. Here are links that actually load on my phone. - https://github.com/swiftlang/swift-java https://github.com/swiftlang/swift-java - https://forums.swift.org/t/improving-swift-support-and-interoperability-experience-for-android/71470 https://forums.swift.org/t/improving-swift-support-and-inter...

aaronbrethorst 2y ago

Plus ça change: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf https://developer.apple.com/library/archive/documentation/Co...

pjmlp 2y ago
The reasoning being different though, back then Apple wasn't sure Objective-C would take off among Mac OS developer crowd, used to Object Pascal and C++, Java support and its high integration with OS APIs was a kind of Plan B. 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.

liuliu 2y ago

PythonKit (from Swift) is underrated but immensely useful in certain scenarios (i.e.: https://engineering.drawthings.ai/from-iphone-ipad-to-mac-enabling-rapid-local-deployment-of-sd3-medium-with-s4nnc-324bd5e81cd5 https://engineering.drawthings.ai/from-iphone-ipad-to-mac-en...). Hopefully JavaKit can find their usefulness too!

wiseowise 2y ago

Will be wildly ironic if Apple pulls uno reverse card and eats Kotlin on Android instead of the other way around.

airstrike 2y ago
It will also be glorious
pjmlp 2y ago
Except contrary to iOS, on Android the C and C++ surface is very small, and calling JNI is a huge performance bottleneck. 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.
Alupis 2y ago
Outside of Apple's ecosystem, is anyone using Swift? Kotlin is growing in all areas, especially backend (being fully embraced by Spring/Spring Boot et al).
- pjmlp 2y ago
  Spring embraces all JVM languages that can bring them new customers.
  - Alupis 2y ago
    They have gone hard on Kotlin. Very hard. For example, in all of Spring/Boot's documentation, you will find Java and Kotlin examples, but not other JVM languages.
    - wiseowise 2y ago
      Because they’re most likely commercial partners with JetBrains.
    - pjmlp 2y ago
      I am old enough to remember when Groovy had similar treatment by Spring.
daghamm 2y ago
Kotlin-Java interoperability is at a completely different level.

glhaynes 2y ago

Cool! One thing Swift is really (maybe uniquely?) strong at is C/C++/Objective-C interop, including mixing "legacy" code with Swift and even replacing it file-by-file with minimal ceremony. Looks like this is aiming to bring a similar level of interop to Swift<->Java.

koito17 2y ago

This gives me flashbacks to the Objective-C / Java bridge [1] from over a decade ago. It makes me wonder how they are dealing with memory management when Java objects are being used from Swift (or Swift objects from Java). This was one (of various) issues that made using the Cocoa Java bridge a bit unpleasant. 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/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf https://developer.apple.com/library/archive/documentation/Co...

lukeh 2y ago
IIRC, the ObjC/Java bridge was first done at NeXT for WebObjects around 1996... almost thirty years ago!
favorited 2y ago
> It makes me wonder how they are dealing with memory management when Java objects are being used from Swift 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/e7d7a217e37d49b326b3367e8299fedcd54cabe2/Sources/JavaKitMacros/JavaClassMacro.swift#L67 https://github.com/swiftlang/swift-java/blob/e7d7a217e37d49b... [1] https://github.com/swiftlang/swift-java/blob/main/Sources/JavaKit/JavaObjectHolder.swift https://github.com/swiftlang/swift-java/blob/main/Sources/Ja... [2] https://github.com/swiftlang/swift-java/blob/main/Sources/JavaKitNetwork/generated/URI.swift https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...

renewedrebecca 2y ago

Oh, well that’s cool!

trigganiggaz 2y ago

[flagged]