Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Jonathan Gibbons]

On 05/23/2016 02:31 PM, Stuart Marks wrote:
> On 5/20/16 4:59 PM, Jonathan Gibbons wrote:
>> While I would agree on the use of one type, not two, for file paths, 
>> I would
>> question the choice to use String instead of Path.  If something is a 
>> file path,
>> use the type system to say so, and use a Path.
>
> Sure, either way will work. I had started with String because the data 
> originates as strings, either from system properties or from string 
> literals.
>
> I switched things around to see what things looked like, starting with 
> Path and converting to String as necessary. Basically I declared the 
> constants using Paths.get(). This meant fileJoin() could disappear, 
> since Paths.get() can concatenate multiple elements.
>
> Paths.get() disappeared from several places inline, and was replaced 
> with a chain of calls to resolve() in a couple others. I had to add 
> toString() in a few places as well.
>
> The pathJoin() helper had to change a bit though. Formerly it 
> concatenated strings with File.pathSeparator; now it has to convert 
> Path objects to strings before doing so. The easiest way to do this 
> was to use a short stream:
>
>     static String pathJoin(Path... paths) {
>         return Arrays.stream(paths)
>                      .map(Path::toString)
> .collect(Collectors.joining(File.pathSeparator));
>     }
>
> Overall I'd say six of one, half a dozen of the other.
>
> s'marks


Yes, and the example is small enough that maybe six of one really does 
balance half a dozen of the other.  But as a general matter of style, I 
think it is preferable to use Path when you really want paths.

That being said, it would be nice to have a method on the Paths API to 
create a search path from a series of Path objects. (your pathJoin method)

-- Jon