+1
-- Jon
On 9/13/18 10:21 AM, Roger Riggs wrote:
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
