RFR: 8298318: (fs) APIs for handling filename extensions [v4]

[Louis Bergelson]

On Fri, 8 Mar 2024 16:32:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> As for the example "http://example.com/subfolder/file.txt?language=english", this is what I see at present:
>> 
>> jshell> Path p = Path.of("http://example.com/subfolder/file.txt?language=english")
>> p ==> http:/example.com/subfolder/file.txt?language=english
>> 
>> jshell> p.withoutExtension()
>> $2 ==> http:/example.com/subfolder/file
>> 
>> jshell> p.getExtension()
>> $3 ==> "txt?language=english"
>> 
>> jshell> p.withoutExtension().toString() + "." + p.getExtension()
>> $4 ==> "http:/example.com/subfolder/file.txt?language=english"
>> 
>> jshell> p.withExtension(p.getExtension())
>> $5 ==> http:/example.com/subfolder/file.txt?language=english
>> 
>> The two forms of the invariant appear satisfied.
>> 
>> Good point about non-default providers.
>
> I would think that manipulations of filename components of a URI/URL would require extracting/converting to a file path first. Path applies to file system names. One could imagine a FileSystem whose Paths were URIs and then yes it could/should implement the file extension related methods to manipulate the file extension and produce valid URIs.

Yes, our software uses a number of alternative file systems in order to treat file access uniformly across different domains.   One for google cloud storage, one for amazon, one for arbitrary http paths, etc.   They're constructed using the `Path.of(URI)` mechanism which matches filesystems by URI scheme.  I just wanted to point out that invariant around handling of toString() wouldn't hold for non-default implementations of Path so maybe it should be stated more generally in terms of path operations instead of in terms of string concatenation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16226#discussion_r1518213334