8207690: Parsing API for classpath and similar path strings

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Sep 10 21:06:17 UTC 2018


OK, I understand the need for quoting, although I wonder how many folk 
have bothered with that up to now (looking at javac, jtreg!) ;-)

I'd stay with

     List<Path> getList(String searchPath)

and then either have people use

getList(searchPath).stream().map(Path::toString).collect(Collectors.toList())

or if we want the extra method, then

     List<String> getListAsStrings(String searchPath)

-- Jon


On 09/10/2018 01:55 PM, Roger Riggs wrote:
> 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
>>>>>
>>>>
>>>
>>
>



More information about the core-libs-dev mailing list