Initial webrev with changes for JDK 9 jrtfs

[Xueming Shen]

(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
>
>