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