8207690: Parsing API for classpath and similar path strings

[Roger Riggs]

Hi Stuart,

The implementation retains the previous handling of empty path elements 
for URLClassPath
in the implementation.  The spec for the new methods is explicit about 
dropping empty elements.

For a library API, it is inadvisable to support implicit context such as 
the current working directory.
I received some offline comments about proposing too many methods and
dropped the variants that supported replacing empty path elements with 
an explicit path.

Keeping the empty path elements would simplify the spec though.

Thanks, Roger


On 9/11/18 4:54 PM, Stuart Marks wrote:
> Hi Roger,
>
>>  110      * Returns a list of path strings parsed from a string with 
>> empty paths removed.
>
> The Unix shell and the Java launcher's -classpath processing treat an 
> empty path entry as the current working directory. (I don't know what 
> happens on Windows.) Removing empty paths thus would seem to change 
> the semantics of search paths, at least on some systems.
>
> s'marks
>
> On 9/10/18 11:16 AM, Roger Riggs wrote:
>> Please review the API and implementation of an API to parse Path 
>> strings.
>> Two methods are added to java.nio.file.Paths to parse a string using 
>> the path separator delimiter
>> and return either List<String> or List<Path>.  Empty path elements 
>> are ignored.
>>
>> For compatibility with current URLClassPath behavior the internal 
>> implementation handles
>> replacement of empty paths.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>
>>
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8208208
>>
>> Thanks, Roger
>>