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
