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
