英文:
Workarounds to import java lib for mingw / ios / linus / other source sets?
问题
我知道依赖于已安装的JVM对某些操作系统源设置进行操作似乎是一个奇怪的用例，让我来说明一下我的用例。
我正在编写一个简单的实用程序，用于封装对steamCMD（https://developer.valvesoftware.com/wiki/SteamCMD）的调用，该工具具有依赖于平台的安装过程。因此，自然而然地，我应该有以下代码：
// commonMain / steamCmdGetter.kt
expect interface SteamCmdGetter {
fun installClient()
}
// [OS] / steamCmdGetter.kt
actual interface SteamCmdGetter { /* ... */ }
另一方面，我的实用程序还需要在文件存储方面进行工作（例如，下载并检查存储中的客户端存在性），因此我还可以使用文件类。
// commonMain / File.kt
expect interface File
我知道JB团队在其教程中有一个明确的建议。
> 我们建议您仅针对具有特定于平台的依赖关系的Kotlin声明使用expected和actual声明。尽可能在共享模块中实现尽可能多的功能，即使这样做需要更多的时间。
然而，尽管有警告，我不希望编写MyFile的实现，以节省为这种常见任务重新发明轮子的工作，但是java.io.File在这个场景中占据主导地位，以至于我在Gradle / Maven上找不到任何Kotlin替代品。
这是否意味着我最终被迫编写MyFile？还是有一种方法可以将Java库导入Kotlin MPP平台的源设置中？
英文:
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?
答案1
得分: 4
首先，只能在jvm和android目标上使用Java库，而不能在Kotlin/Multiplatform提供的其他目标上使用。实际上，这正是一个仅使用Kotlin/JVM的目标子集。Kotlin/JS和Kotlin/Native都不提供与Java的互操作性，它们有自己的互操作能力。详细信息请参见此页面。关于特定的文件操作。很可能答案是肯定的，您将需要针对每个目标实现它。这种工作通常是平台特定的，因为它几乎完全依赖于操作系统的实现。然而，您所寻找的功能的一部分应该明确地在platform.posix.* 平台库中找到，即使它看起来更像是C风格的。
附言：我在网上进行了快速搜索，找到了这个社区库的列表，也许会有所帮助。此外，kotlinlang的Slack社区（在此处找到链接4）可能会有一些有趣的解决方案可以分享。
英文:
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.<br> 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.
P.S. 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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论