8207690: Parsing API for classpath and similar path strings

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Sep 12 17:55:02 UTC 2018



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
>



More information about the core-libs-dev mailing list