On 11 Sep 2018, at 14:18, Roger Riggs <roger.riggs@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@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.