(5) JrtFileSystemProvider.copy(src, dst, ...options)
The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs itself is
a readonly, I'm not sure if we want to support the operation of copying
a "file" output jrtfs. The copy/paste "copyToTarget" appears to be functional,
if it's not a "AbstractJrtPath".
On 03/14/2016 04:08 PM, Xueming Shen wrote:
(1) JrtFilePath: it does not seem to help performance to use the byte[] as the
internal storage.
(2) AbstractJrtFilesystem.java
getPathMatcher:
....
if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) {
expr = JrtUtils.toRegexPattern(input);
} else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) {
expr = input;
} else {
throw new UnsupportedOperationException("Syntax '" + syntax
+ "' not recognized");
}
(3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy?
(4) JrtFilesystem.nodesToIterator()
Stream has a "iterator() method. why need a collect() here? different
performance?
for example
private Iterator<Path> nodesToIterator(AbstractJrtPath dir, List<Node>
childNodes) {
return childNodes.stream()
.map(child ->
(Path)dir.resolve(toJrtPath(child.getNameString()).getFileName()))
.iterator();
}
sherman
