8207690: Parsing API for classpath and similar path strings
Peter Levart
peter.levart at gmail.com
Wed Sep 12 16:31:22 UTC 2018
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>...
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
More information about the core-libs-dev
mailing list