8207690: Parsing API for classpath and similar path strings
Roger.Riggs at Oracle.com
Mon Sep 10 20:34:43 UTC 2018
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 ->
* b) Drop the other API, always doing the conversion to Path and
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.
* 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>
Without static imports looks like:
var files = Paths.toStringList("a;b;c").stream()....
var searchpath = Paths.toPathList("x;y;z");
On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
> 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
> 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
>> 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.
>> Thanks, Roger
More information about the core-libs-dev