Java NIO is a very low level library, and it doesn’t really make sense on some platforms (Scala.js) and could be very different on other libraries (scala-native). If Scala.js would add suppor this library via platforms like node.js, I suspect it would be very hard to make a proper interface to Java NIO within Scala.js and for scala-native I suspect that the use case in scala-native (low level accesss to C/C++ libraries) would mean that implementing Java NIO would be less than ideal
The collections analogy isn’t apt, its an apples to oranges comparison. Collections API is designed to be high level, IO access unless its a very high level API isn’t (unless we deliberately design the scope of this SPP to be very small which gets to my earlier point)
java.io.File
is deliberately a high level API, java.nio
is not (at least in its entirety of its design, i.e. memory mapping of files and channels). It provides very low level access to filesystem operations, and also its idea of “async” (or non blocking) is quite different to what typical non blacking actions look like in Scala.
I for example do not see how channels would work with Scala.js, and memory mapped files isn’t something thats also official supported with node.js
To be clear, if we wan’t this SPP to just be very high level without async or any other features like that, than the better abstraction would actually be Java’s original java.file
and not java.nio
.