This PR adds most extensions on `java.io.File` in `kotlin.io` to `java.nio.Path`. This includes extensions from `FileReadWrite.kt`, `Utils.kt`, and `FileTreeWalk.kt`.
I attempted to keep the implementations, documentation, and tests as similar as possible to the existing implementations.
I am happy to add, remove, or move to separate PRs any of the functions of this PR.
### `File` extensions that were not added to `Path`
##### `createTempDir`, `createTempFile`
These functions have no `File` parameters, so can't be overloaded. Equivalents exist as `Files.createTempFile()` and `Files.createTempDirectory()`.
##### `startsWith`, `endsWith`, `normalize`, `resolve`, `resolveSibling`
These exist as member functions on `Path`
##### `relativeTo`, `relativeToOrNull`, `relativeToOrSelf`, `toRelativeString`, `toRelativeStringOrNull`
This functionality exists as the `Path.relativize` member function, which is equivalent to `relativeTo`, but with the receiver and parameter flipped. `foo.relativeTo(bar)` is equivalent to `bar.relativize(foo)`. We could potentially add a `relativizeOrNull` extension to make that pattern simpler.
##### `isRooted`
`Path` has a `root` method, so `isRooted` is equivalent to `root != null`
### New extensions
All of the simple boolean attribute checks from `java.nio.Files` were added as extensions on `Path`. These extensions are used commonly enough that it seems worth supporting them. This functionality for `File` is implemented as member methods.
The following `Path` extensions were added:
- `exists`
- `isDirectory`
- `isExecutable`
- `isFile`
- `isHidden`
- `isReadable`
- `isSameFile`
- `isSymbolicLink`
- `isWritable`
Some of these extensions take options that are forwarded to their `Files` method, so all of the extensions were implemented as functions rather than properties for consistency.
Additionally, `Path.listFiles` was added to match the `File.listFiles` method. One motivation for its addition was that it's used several times in the implementation of other file extensions. The way to list directory contents with `java.nio` is via `Files.newDirectoryStream()`, which returns an iterable object that must be closed to avoid leaking resources. It's difficult to use correctly with functions like `map` and `filter`, so this extension was added as a simpler, less error-prone alternative.
### Other changes
I added overloads of several of the read-write that take `OpenOptions` to expose the greater control that `java.nio` introduces. For example, you can use `printWriter(APPEND)` to create a `PrintWriter` that doesn't delete the contents of an existing file.
All the new extensions throw exceptions (such as `NoSuchFileException`) from `java.nio` rather than the copies from `kotlin.io`. The `kotlin.io` copies take `File` objects as parameters, and so aren't compatible with `Path`s.
### Address review comments
- Move varargs parameters to the last position
- Remove PathTreeWalk
#KT-19192
The next step for JVM IR adoption in our project is going to be enabling
`kotlin.build.useIR`, but keeping `kotlin.build.useIRForLibraries`
disabled until we fix all remaining ABI incompatibility issues for
library code.
Make sure that `message` and `cause` are properly configured
- synchronize IR BE and Legacy behaviour
- fix corresponding IR lowering
- fix JS IR core runtime
- add test
- fix KT-39964
Unlike signed integers, a larger unsigned type does not mean a lower
minimum value, so `x - 1` can overflow even if `x` is casted to a larger
type.
#KT-42186 Fixed
This lessens the possibility that kotlin plugin will get different
variants of builtins in the classpath, thus making builtins resources
loading less order-dependent.
JVM IR backend doesn't support old coroutines, so we disable it via
-Xno-use-ir, just as for the main source set. This option has no effect
for the current master builds, but will be necessary once JVM IR is
enabled project-wide.
The error SIGNED_CONSTANT_CONVERTED_TO_UNSIGNED is suppressed in this
file, and JVM IR is not able to generate comparisons of UInt and Long
(KT-41780).
Its support complicates JS StringBuilder implementation with no actual
performance improvements. Benefits of having capacity() function
in common code are also not completely clear.
Relates to KT-33069
#KT-40168
AJ