Hello. Does anyone know the justification for <kot...
# stdlib
m
Hello. Does anyone know the justification for kotlin.io being a set of extensions to
java.io.File
instead of
java.nio.file.Path
? I assume this is to do with the legacy Java 1.6 support but it's quite awkward for programs that want to benefit from the NIO features like in-memory file systems, etc.
n
that’s a great question indeed 💡
e
you must have a new enough jvm target but that should be the default now
m
Yes, but e.g. walkFileTree is only on File
e
a Kotlin wrapper isn't as useful for Path since there's Files.walkFileTree, IMO. but you could file a YT issue if you think there's a reason for it
m
The Kotlin code has a quite nice function to do bottoms-up as well as top-down walks. But yeah it's a minor thing I guess.
j
It was dropped from the initial NIO extension PR. Feel free to send one focusing solely on adding that where we can discuss the right API.
p
These are the gaps that we still use our own extensions methods for:
Copy code
Path.walk()           // -> Files.walk()
Path.createTempFile() // -> Files.createTempFile()
Path.writeString()    // -> Files.writeString() (more efficient than Path.writeText())
Path.readString()     // -> Files.readString() (more efficient than Path.readText())
Path.deleteRecursively() // -> Files.walk()
Path.createParentDirectories() // dedicated method because we need this a lot
👍 2
r
These would all be nice to have, imo, except maybe the last one which could possibly be done as
Path.parent.mkdir(true)
or similar
e
path.parent?.createDirectories()
but yeah, those sound good to raise somewhere more formal
p
the last one is a convenience method that we use all over the place:
Copy code
fun Path.createParentDirectories(vararg attributes: FileAttribute<*>): Path =
  apply { parent?.createDirectories(*attributes) }
usage:
path.createParentDirectories().writeString("hello")
m
Thanks all, very helpful.
Seems it's just waiting for someone to step up and submit PRs.