8207690: Parsing API for classpath and similar path strings

[Roger Riggs]

Hi,

Defining a SearchPath class does have a number of benefits as Mark outlined.

Consider:

public class SearchPath {
     public static SearchPath of(String searchPath) {...}
public static SearchPath of(List<String> elements) {...}
public Stream<String> stream() {...}
public List<String> asList() {...}
     public String toString() {...}
     private SearchPath() {};
}

A SearchPath can be constructed from various forms of search path 
elements and can create other forms as needed.
As a class it would be extensible and can start small and grow as needed.

Examples:
         List<String> list = SearchPath.of("a:b:c").asList();

     Path p = SearchPath.of("x:y:z").stream()
          .filter(Predicate.not(String::isEmpty))
          .map(Path::of)
              .filter(Files::isDirectory)
              .filter(q -> Files.exists(q.resolve("x.jar)))
          .findFirst()
          .orElseThrow();

If that seems like a reasonable base, I (or some other volunteer) can 
flesh it out with the suggestions.

Thanks, Roger

On 9/13/2018 3:33 AM, Alan Bateman wrote:
> On 11/09/2018 17:04, Stephen Colebourne wrote:
>> :
>> This is a broader question for new methods in the JDK, not just this
>> one. I don't think anyone has come up with a "style guide" for when to
>> use Stream returning as opposed to list-returning methods.
>>
>> What I can say is that I think List is the better fit here, because:
>> - the result is not large
>> - the result may well be stored somewhere (method should guarantee
>> result is immutable)
>> - a List is simpler conceptually than Stream as a result type (eg.
>> serial vs parallel)
>>
>> Personally, I only tend to return Stream if I the particular method is
>> returning a very large data set.
>>
> There are several discussion points around this aspect of API design. 
> One of the most important questions to ask is whether a stream or 
> collection is more useful to the caller. For the API under discussion 
> then we have several examples in the JDK that process the class path 
> or module path. One example involves mapping the elements of the class 
> path to file URLs and into an array to create a URLClassLoader. 
> Another maps the elements to Path objects and into an array to create 
> a ModuleFinder. Another maps the elements to Path objects and performs 
> an action on each element. Stuart brings up the empty path case which, 
> depending on context, may need to be filtered. The examples so far 
> iterate over the elements once and an intermediate/cached collection 
> isn't needed. On the other hand, I think Roger's main use-case is 
> representing the value of the java.class.path property as a List<Path> 
> which will may involve caching an unmodifiable list.
>
> -Alan
>