Я знаю, что это довольно странный вариант использования - зависеть от установки 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, которые имеют зависимости, зависящие от платформы. Лучше реализовать как можно больше функций в общем модуле, даже если это займет больше времени.
Тем не менее, вопреки предупреждениям, я не хочу писать MyFile реализацию, чтобы сэкономить усилия на изобретении колеса для такой общей задачи, но java.io.File был настолько доминирующим в сцене, что я не мог найти никаких альтернатив Kotlin в Gradle / Maven.
Означает ли это, что в конце я должен написать MyFile? Или есть обходной путь для импорта библиотек Java в исходные наборы платформы Kotlin MPP?
