API for parsing path strings

[Roger Riggs]

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
>>
>