API for parsing path strings

[Jonathan Gibbons]

Hi Roger,

The point about early parsing is a weak one, because it would mostly 
just seem to apply to JDK itself. That being said, a variant of this 
argument is that it allows folk to choose how to map strings to Paths, 
e.g. using a custom (non-default) file system, and that argument is more 
compelling.

The point about handling the individual possible InvalidPathException is 
a good one.

Having an extra method that returns List<Path> and which specifies that 
the character sequences in between the path separator characters must be 
valid paths would also be good.

-- Jon


On 7/23/18 11:04 AM, Roger Riggs wrote:
> Hi Jon,
>
> I agree that supporting Paths leads people in the right direction.
> Two considerations led me to propose the simpler String version first.
> 1.  Early parsing of paths can occur before the file systems that 
> support Path have been initialized.
> 2.  There is an additional exception that can occur when creating a 
> Path (InvalidPathException)
> and the caller may want to handle it individually.
>
> Adding another method that returns List<Path> is a straightforward 
> addition.
> Keeping the string version may make adoption easier.
>
> Thanks, Roger
>
> On 7/23/18 1:53 PM, Jonathan Gibbons wrote:
>> Roger,
>>
>> Having written internal library code for both javac and jtreg to do 
>> what you suggest, I would support such an API.
>>
>> I note that as well as parsing system properties, it would also be a 
>> useful API for command-line tools that accept paths as options.
>>
>> However, I would suggest that it is more appropriate to return a 
>> List<Path> than a List<String>.  It is better to bias the API towards 
>> an appropriate type (i.e. Path) than to leave it to the user to 
>> create a stream to do the conversion. Those folk that still want a 
>> File can still create the stream to do the conversion if they so desire.
>>
>> By converting to Paths as part of the API, it becomes a clearer point 
>> to specify and document the possibility of InvalidPathException.
>>
>> -- Jon
>>
>>
>> On 7/19/18 12:39 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Parsing of paths such as the values of properties java.class.path 
>>> and java.library.path
>>> do not have  direct support in the Java API.
>>> There are several implementations within OpenJDK and a few 
>>> variations exist with regard to
>>> treatment of empty path elements and on Windows support for quoting.
>>>
>>> Would it be useful to have an API such as the following:
>>>
>>>     /**
>>>      * Returns a list of paths parsed from a string separated by 
>>> {@link File#pathSeparator}.
>>>      * All characters except the {@link File#pathSeparator} are 
>>> allowed.
>>>      * Some operating systems support quoting segments of the string
>>>      * potentially including {@code pathSeparator} characters.
>>>      * Empty paths, identified by leading, trailing, and adjacent 
>>> separator characters,
>>>      * can be omitted or replaced with a non-null provided path.
>>>      *
>>>      * @implNote
>>>      * On Windows, zero or more characters between double-quotes 
>>> ({@code "}) are included
>>>      * literally in the path, regardless of whether they are valid 
>>> in a path.
>>>      *
>>>      * @param path a string containing paths separated by the {@link 
>>> File#pathSeparator}
>>>      * @param emptyPath a path to replace an empty path or {@code 
>>> null} to ignore empty paths
>>>      * @return an immutable list of strings for each path; {@code 
>>> non-null}
>>>      */
>>>     public static List<String> parsePathStrings(String path, String 
>>> emptyPath) { ...}
>>>
>>> There are of course, possible variations and convenience versions 
>>> but the API should be kept to the essentials.
>>> With java.util.streams it becomes easy to process each component or 
>>> to map the strings to Files or Path.
>>>
>>> Suggestions welcome, Roger
>>>
>>
>