Hi Roger,
The point about early parsing is a weak one, because it would mostly
just seem to apply to JDK itself. That being said, a variant of this
argument is that it allows folk to choose how to map strings to Paths,
e.g. using a custom (non-default) file system, and that argument is more
compelling.
The point about handling the individual possible InvalidPathException is
a good one.
Having an extra method that returns List<Path> and which specifies that
the character sequences in between the path separator characters must be
valid paths would also be good.
-- Jon
On 7/23/18 11:04 AM, Roger Riggs wrote:
Hi Jon,
I agree that supporting Paths leads people in the right direction.
Two considerations led me to propose the simpler String version first.
1. Early parsing of paths can occur before the file systems that
support Path have been initialized.
2. There is an additional exception that can occur when creating a
Path (InvalidPathException)
and the caller may want to handle it individually.
Adding another method that returns List<Path> is a straightforward
addition.
Keeping the string version may make adoption easier.
Thanks, Roger
On 7/23/18 1:53 PM, Jonathan Gibbons wrote:
Roger,
Having written internal library code for both javac and jtreg to do
what you suggest, I would support such an API.
I note that as well as parsing system properties, it would also be a
useful API for command-line tools that accept paths as options.
However, I would suggest that it is more appropriate to return a
List<Path> than a List<String>. It is better to bias the API towards
an appropriate type (i.e. Path) than to leave it to the user to
create a stream to do the conversion. Those folk that still want a
File can still create the stream to do the conversion if they so desire.
By converting to Paths as part of the API, it becomes a clearer point
to specify and document the possibility of InvalidPathException.
-- Jon
On 7/19/18 12:39 PM, Roger Riggs wrote:
Hi,
Parsing of paths such as the values of properties java.class.path
and java.library.path
do not have direct support in the Java API.
There are several implementations within OpenJDK and a few
variations exist with regard to
treatment of empty path elements and on Windows support for quoting.
Would it be useful to have an API such as the following:
/**
* Returns a list of paths parsed from a string separated by
{@link File#pathSeparator}.
* All characters except the {@link File#pathSeparator} are
allowed.
* Some operating systems support quoting segments of the string
* potentially including {@code pathSeparator} characters.
* Empty paths, identified by leading, trailing, and adjacent
separator characters,
* can be omitted or replaced with a non-null provided path.
*
* @implNote
* On Windows, zero or more characters between double-quotes
({@code "}) are included
* literally in the path, regardless of whether they are valid
in a path.
*
* @param path a string containing paths separated by the {@link
File#pathSeparator}
* @param emptyPath a path to replace an empty path or {@code
null} to ignore empty paths
* @return an immutable list of strings for each path; {@code
non-null}
*/
public static List<String> parsePathStrings(String path, String
emptyPath) { ...}
There are of course, possible variations and convenience versions
but the API should be kept to the essentials.
With java.util.streams it becomes easy to process each component or
to map the strings to Files or Path.
Suggestions welcome, Roger
