On 9/12/18 9:31 AM, Peter Levart wrote:
On 09/12/2018 04:30 PM, Roger Riggs wrote:
Hi Stuart,
The implementation retains the previous handling of empty path
elements for URLClassPath
in the implementation. The spec for the new methods is explicit
about dropping empty elements.
For a library API, it is inadvisable to support implicit context such
as the current working directory.
I received some offline comments about proposing too many methods and
dropped the variants that supported replacing empty path elements
with an explicit path.
Keeping the empty path elements would simplify the spec though.
...and it's easy to .filter() them out if the parsing method returns
Stream<String>...
or .map() them to some default value, such as the current working directory.
-- Jon
Regards, Peter
Thanks, Roger
On 9/11/18 4:54 PM, Stuart Marks wrote:
Hi Roger,
110 * Returns a list of path strings parsed from a string with
empty paths removed.
The Unix shell and the Java launcher's -classpath processing treat
an empty path entry as the current working directory. (I don't know
what happens on Windows.) Removing empty paths thus would seem to
change the semantics of search paths, at least on some systems.
s'marks
