2018/9/13 10:21:26 -0700, roger.ri...@oracle.com:
> Consider:
>
> public class SearchPath {
> public static SearchPath of(String searchPath) {...}
> public static SearchPath of(List elements) {...}
> public Stream stream() {...}
> public List asList() {...}
> public String toString() {...}
>
+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 elements) {...}
public Stream st
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 elements) {...}
public Stream stream() {...}
public List asList() {...}
public Strin
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 bette
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 l
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 im
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 dir
Hi,
My original intention was to provide minimal support for parsing a
property value
and handling OS specific behaviors (quoting).
java.nio.file.Paths is a bit of backwater (now that Path.of was added)
and its factories are dedicated to handling Paths.
I considered a new type representing
On Tue, Sep 11, 2018 at 9:04 AM, Stephen Colebourne
wrote:
> What I can say is that I think List is the better fit here, because:
> - the result is not large
If we're talking about classpath splitting ...
At Google, we continue to struggle with classpaths that have on the
order of 10,000 elemen
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 woul
2018/9/11 4:50:49 -0700, chris.hega...@oracle.com:
>> On 11 Sep 2018, at 10:24, Alan Bateman 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 re
2018/9/11 8:05:23 -0700, roger.ri...@oracle.com:
> Right, that is a description of the shell environment on Windows and how
> the java launcher behaves.
> On Windows the launcher expands wildcards when evaluating classpath from
> the environment
> and the command line args. After they are expande
On Tue, 11 Sep 2018 at 10:25, Alan Bateman 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
> rathe
Clarified.
So classpath can call this new method first and then expand * to all JAR files.
This is fine.
Thanks
Max
> On Sep 11, 2018, at 11:05 PM, Roger Riggs wrote:
>
> Hi Max,
>
> Right, that is a description of the shell environment on Windows and how the
> java launcher behaves.
> On W
Hi Max,
Right, that is a description of the shell environment on Windows and how
the java launcher behaves.
On Windows the launcher expands wildcards when evaluating classpath from
the environment
and the command line args. After they are expanded the java.class.path
property is set.
The pro
" , "jonathan gibbons"
> , "core-libs-dev"
>
> Envoyé: Mardi 11 Septembre 2018 16:29:06
> Objet: Re: 8207690: Parsing API for classpath and similar path strings
> On 11/09/2018 14:09, Roger Riggs wrote:
>>
>> Streams are fine and easy to get fr
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762
This is not about the wildcard parsed by the shell. The bug synopsis mentions
"classpath" and I am just curious if it covers this feature. I don't have my
own user case for it.
--Max
> On Sep 11, 2018, at 10:
Hi,
What would the use case be for that?
A search path is usually just a sequence of file paths; wildcard
expansion is not includes.
Wildcards are significant only in shell contexts, though the expansion
is done by the shell on Unix and by the application on Windows; it
would add a fair bit
Is the wildcard character allowed in the input?
I'm thinking of the wildcard support in classpath.
--Max
> On Sep 11, 2018, at 2:16 AM, Roger Riggs wrote:
>
> Please review the API and implementation of an API to parse Path strings.
> Two methods are added to java.nio.file.Paths to parse a str
On 11/09/2018 14:09, Roger Riggs wrote:
Streams are fine and easy to get from a List; but overall are a much
higher overhead than the list itself.
And they can't be stored or re-used. Which would mean re-parsing the
string again.
I think returning Stream will provide the most flexibility. The
> On 11 Sep 2018, at 14:18, Roger Riggs wrote:
>
> Hi Chris,
>
> On 9/11/18 7:50 AM, Chris Hegarty wrote:
>>> On 11 Sep 2018, at 10:24, Alan Bateman wrote:
>>>
>>> On 10/09/2018 21:55, Roger Riggs wrote:
Nope! there's quoting on Windows that gets short changed with that work
aroun
Hi Chris,
On 9/11/18 7:50 AM, Chris Hegarty wrote:
On 11 Sep 2018, at 10:24, Alan Bateman 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 me
Hi Alan,
On 9/11/18 5:24 AM, Alan Bateman 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 collect
> On 11 Sep 2018, at 10:24, Alan Bateman 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
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 lik
OK, I understand the need for quoting, although I wonder how many folk
have bothered with that up to now (looking at javac, jtreg!) ;-)
I'd stay with
List getList(String searchPath)
and then either have people use
getList(searchPath).stream().map(Path::toString).collect(Collectors.toList(
Hi Jon,
On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
Roger,
I had in mind your first "disambiguate" suggetion
(searchPathToStrings, searchPathToPaths)
but I note your initial comment "Is the search path the input string
or the return value? Well its both, but with different structure. "
Roger,
I had in mind your first "disambiguate" suggetion (searchPathToStrings,
searchPathToPaths)
but I note your initial comment "Is the search path the input string or
the return value? Well its both, but with different structure. "
Since we have
Paths.get
how about
List Paths.ge
Hi Jon, Alan,
No surprise and suggestions welcome! :)
Since we don't have return type overloads, the name has to encode the
return type (or the important aspects of it).
Is the search path the input string or the return value? Well its both,
but with different structure.
Remove the ambigui
On 10/09/2018 19:28, Jonathan Gibbons wrote:
Roger,
You've run into the standard naming ambiguity problem of "when is a
path a search path, with elements separated by File.pathSeparator
(e.g. class path, source path), and when is it a file path, with
elements separated by File.separator (e
Roger,
You've run into the standard naming ambiguity problem of "when is a path
a search path, with elements separated by File.pathSeparator (e.g. class
path, source path), and when is it a file path, with elements separated
by File.separator (e.g. a nio.file.Path identifying a file or directo
Please review the API and implementation of an API to parse Path strings.
Two methods are added to java.nio.file.Paths to parse a string using the
path separator delimiter
and return either List or List. Empty path elements are
ignored.
For compatibility with current URLClassPath behavior the
32 matches
Mail list logo
