为 mingw / ios / linus / 其他源集导入 java lib 的解决方法？

Question

I am aware that it's quite a weird use case to depend on having JVM installed for some OS source sets, allow me to go through my use case.

I'm writing a simple utility to wrap calls for the steamCMD ( https://developer.valvesoftware.com/wiki/SteamCMD ), which has platform dependent installation procedures. So, naturally I should have

// commonMain / steamCmdGetter.kt
expect interface SteamCmdGetter {
    fun installClient()
}
// [OS] / steamCmdGetter.kt
actual interface SteamCmdGetter { /* ... */ }

On the other hand, my utility also needs to do work with the file storage (for example, downloading and checking client existence in storage), so I could also use a file class.

// commonMain / File.kt
expect interface File

I am aware that the JB team has an explicit recommendation on its tutorials.

We recommend that you use expected and actual declarations only for Kotlin declarations that have platform-specific dependencies. It is better to implement as much functionality as possible in the shared module even if doing so takes more time.

Yet, against the warnings I wish not to write a MyFile implementation to save efforts from reinventing the wheel for such a common task, but java.io.File has been so dominant in the scene that I could not find any Kotlin alternatives on Gradle / Maven.

Does this means I am forced to write MyFile in the end? Or is there a workaround for importing Java libraries to Kotlin MPP platform sourceSets?

Answer 1

First of all, one can use Java libraries only for jvm and android targets, not the others provided by the Kotlin/Multiplatform. In fact, this is exactly a targets subset that is using Kotlin/JVM. Neither Kotlin/JS nor Kotlin/Native provide interoperability with Java, they has their own interop capabilities. See this page to get some details on the difference.
About working with files in particular. Most probably the answer is yes and you'll have to implement it per-target. This kind of work is usually platform-specific, as it hardly rely on the OS implementation. However, part of the functionality you search for should be definitely found in the platform.posix.*platform library , even if it would appear more C-stylish.

---

PS Quick search across the Web led me to this community libraries list , maybe it would help. Also, kotlinlang Slack community(find link here ) may have some interesting solutions to share.