How can you get the java.io.File or even better th...

# io

[hfhbd]

How can you get the java.io.File or even better the java.nio.file.Path from a kotlinx.io.Path on the JVM? Use-case, I want to get a WatchService from a kotlinx.io.path on the JVM only.

[Michael Paus]

What about a simple

fun kotlinx.io.files.Path.toNioPath(): java.nio.file.Path = java.nio.file.Path.of(this.toString())

[hfhbd]

Hm, yeah that should work, but I don't like to depend on toString()

[Michael Paus]

Why not? APIs are full of path strings anyway.

[jw]

Probably won't work for paths which are not valid utf-16.

[hfhbd]

Valid point, but I won't support non utf-16 paths anyway. I only support ascii and the max length of the file name must be 22 or less 😄

[jw]

Haha, big MS-DOS vibes there

[hfhbd]

Well, it is older than MS-DOS, the convention based on the limitations of the mainframe in the seventies...

[Michael Paus]

In which century are you living guys 🤪? Have you ever written a command line utility? How did you get your paths? As strings, right? So please show me any relevant example on the JVM where this conversion via a string doesn't work 🧐.

[hfhbd]

I do use the toString() method for my use-case, but like Jake said, it might not work in all cases.

[Michael Paus]

I'll believe it when I see it.

[jw]

There's a reason modern programming languages don't represent paths as strings.

[jw]

Of if they do, they use a dedicated type which doesn't attempt to parse them as being valid unicode

[Filipp Zhinkin]

It most likely not the case with <http://kotlinx.io|kotlinx.io>.files.Path in particular, as it handles things badly, but on Unix systems file names (and path segments) are not obliged to be valid string and are just sequences of bytes (the only restriction - the should not contain / and \0 ).
Thus, if there's a file with a name that is not a valid utf8 sequence, you can still get a Path pointing to it using java.nio.file.Files.list (Java's Unix Paths holds byte array with a file name internally, not a string), but the conversion via .toString() will no longer work for such a Path .

[Michael Paus]

All modern filesystems practically use some form of UTF. Here is a list which AI created for me. Only the OP can decide whether these more esoteric cases are relevant for him or not.

| File System | Internal Representation | Key Characteristic                          |
|-------------|-------------------------|---------------------------------------------|
| NTFS        | UTF-16LE                | Stores names as 16-bit Unicode code units.  |
| ext4 / XFS  | Opaque Byte String      | Encoding-agnostic; usually treated as UTF-8.|
| APFS        | UTF-8                   | Modern Apple standard; normalization-aware. |
| HFS+        | UTF-16                  | Legacy Apple; forces NFD normalization.     |
| FAT32       | OEM / UTF-16            | Uses UTF-16 specifically for Long Filenames.|

[jw]

All modern days practically have 24 hours.

[jw]

All modern minutes practically have 60 seconds.

[jw]

All modern years practically have 365 days!

[Filipp Zhinkin]

| ext4 / XFS  | Opaque Byte String      | Encoding-agnostic; usually treated as UTF-8.|

Meaning these FSs know nothing about UTF-8, and it's up to an application how to interpret the byte string.