8207690: Parsing API for classpath and similar path strings

[Jonathan Gibbons]

Roger,

I had in mind your first "disambiguate" suggetion (searchPathToStrings, 
searchPathToPaths)
but I note your  initial comment "Is the search path the input string or 
the return value?  Well its both, but with different structure. "

Since we have
     Paths.get

how about
     List<Path> Paths.getList(String searchPath)

I'd be less inclined to give formal support to converting to a 
List<String>. Those folk that want that could/should
be using String.split(File.pathSeparator) or something like that.

-- Jon

On 09/10/2018 01:34 PM, Roger Riggs wrote:
> Hi Jon, Alan,
>
> No surprise and suggestions welcome!  :)
>
> Since we don't have return type overloads, the name has to encode the 
> return type (or the important aspects of it).
> Is the search path the input string or the return value?  Well its 
> both, but with different structure.
>
> Remove the ambiguity:
>
>  * a) Drop one of the APIs, leaving only the return of List<String> and
>    push the conversion to Path to the consumer.
>    e.g. List<Path> files = toSearchPath(String).stream().map(s ->
>    Paths.of(s)).collect(Collectors.toList());
>  * b) Drop the other API, always doing the conversion to Path and
>    throwing exceptions.
>    e.g. List<Path> toSearchPath(String);
>    The Caller can get the string or file by calling toString() or
>    toFile(); potentially wasting the effort to check the path syntax.
>
> Disambiguate:
>
>  * List<String> searchpathToStrings(s); List<Path> 
> searchpathToPaths(s); or
>    var files = Paths.searchpathToStrings("a;b;c");
>    var searchpath = Paths.searchpathToPaths("x;y;z");
>  * List<Path> toPathList(String searchpath); List<String>
>    toStringList(String searchpath)
>    Without static imports looks like:
>    var files = Paths.toStringList("a;b;c").stream()....
>    var searchpath = Paths.toPathList("x;y;z");
>  * ???
>
> Thanks, Roger
>
> On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
>> Roger,
>>
>> You've run into the standard naming ambiguity problem of "when is a 
>> path a search path, with elements separated by File.pathSeparator 
>> (e.g. class path, source path), and when is it a file path, with 
>> elements separated by File.separator (e.g. a nio.file.Path 
>> identifying a file or directory)?"
>>
>> This shows up most obviously in the method confusingly named 
>> "pathToPaths".
>>
>> In other contexts (javac, jtreg, etc) I've tried to use the term 
>> "search path" to describe the string that is a sequence of elements 
>> separated by File.pathSeparator.
>>
>> -- Jon
>>
>> 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
>>>
>>
>