Should it? My understanding is that those tests don't use zipfs directly
from zipfs module, it access it via java.base's FileSystemProvider interface.
It depends on the jdk runtime to pick up the zipfs "provider" to function. So
if the jdk runtime fails to pick up the zipfs module for whatever reason,
that's something we want to detect as well?
-Sherman
On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote:
Hi.
Should the tests also declare “@modules jdk.zipfs”?
Shura
On May 25, 2016, at 9:39 AM, Xueming Shen<xueming.s...@oracle.com> wrote:
Hi,
Please help review the changes for the following zipfs related bug fixes
JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when
invoking register()
JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result
JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending
with slash /
JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize()
issue:
https://bugs.openjdk.java.net/browse/JDK-8147539
https://bugs.openjdk.java.net/browse/JDK-8153248
https://bugs.openjdk.java.net/browse/JDK-8146754
https://bugs.openjdk.java.net/browse/JDK-8139956
webrev:
http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/
The changes are relative easy.
(1) ZipPath.initOffsets() should deal with empty path specially, as the
UnixPath impl does
(2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care
of at
ZipPath.normalize(byte[], int), but is missed in the "main" method)
(3) ZipPath.register() should throw PME as suggested.
Thanks,
Sherman
