8207690: Parsing API for classpath and similar path strings

[Chris Hegarty]

> On 11 Sep 2018, at 14:18, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 9/11/18 7:50 AM, Chris Hegarty wrote:
>>> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 10/09/2018 21:55, Roger Riggs wrote:
>>>> Nope! there's quoting on Windows that gets short changed with that work around.
>>>> 
>>>> Other opinions?, Suggestions?
>>> One suggestion is reduce this down to one method that returns a stream rather than a collection. It could work lazily if you want. Something like:
>>> 
>>>   Stream<String> splitSearchPath(String input)
>> I agree with Alan, this seems like the lowest-order primitive.
> How can that be? The Stream creates a lot more objects and takes even more to use it.

I guess it depends on the use-case that you are trying to 
address. In the cases that I sited, a Stream would likely be
more appropriate since the calling code requires to iterate
over the entries, rather than store them as-is. You are
probably thinking of different use-cases.

> It can't be stored or re-used and has higher overhead that can't easily be understood.

.collect(toList()) - which, again, depending on use-case
may be more or less common than entries.stream().

>> I refreshed my memory of search path splitting from the `jmod` tool,
>> where such an API would be useful ( if we weren’t using joptsimple ).
>> There are two separate use cases, ClassPathConverter, and
>> DirPathConverter ( in JmodTask ), both of which resolve each String
>> path value against the current working directory, and do some
>> context specific validation.
> Command line tools are more likely to resolve against the current directory
> List<String> is least common but still pushes more to the developer.

Exactly. My comments are from the perspective of writing a
command line tool, since that is the only direct experience
I have with such functionality. You may have different use-
cases in mind.

-Chris.