Hello,
Long time Tapir user here, so far very happy with it.
The other day I wanted to serve files in a jar/zip file with correct content ranges and the usual things you would expect from static files.
This ended up not working because Path.toFile is not supported by the filesystem provider from jdk.zipfs.
It makes sense as Path.toFile and vice versa is really meant for interop with the legacy java.io.File API only.
For example, a Path from GitHub - google/jimfs: An in-memory file system for Java 7+ will fail the same way.
Looking at the source, Tapir constantly round-trips this conversion, going from a Path to a File for use in FileRange then back to a Path.
In the vast majority of the cases, Path is the expected (or supported) type for both server and client interpreters.
I think sticking to the NIO API everywhere and only calling toFile when absolutely required is probably the most compatible option.
I tested this change locally (it’s mostly straightforward) and the tests seems to be passing (it’s taking a while).
Would this be something to open a PR for? The biggest issue I can think of is binary compatibility.
Tom