This issue is filed to track changes suggested during code review in jigsaw-dev

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006816.html

Email content cut-pasted here for convenience:


(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