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