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