8207690: Parsing API for classpath and similar path strings

[Roger Riggs]

Hi Jon,

On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
> 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)
Not bad, but...

Perhaps, List<String> Paths.getListAsStrings(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.
Nope!  there's quoting on Windows that gets short changed with that work 
around.

Other opinions?, Suggestions?

Thanks, Roger

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