The tests under test/jdk/nio/zipfs are intended to test the zipfs implementation and hence they fail if the zipfs provider does not exist. So I agree with Shura that they should have @modules jdk.zipfs that enables test selection per the @modules declaration.
Mandy > On May 25, 2016, at 11:06 AM, Alexandre (Shura) Iline > <alexandre.il...@oracle.com> wrote: > > Sherman, > > Not declaring any module dependencies in test is equivalent to declaring that > the test only depends on java.base. In such case, the test will be picked up > for execution by JTReg, no matter what modules are available. One way to test > such behavior would be to supply -javaoptions:”-limitmods java.base” in the > JTReg command line. The tests will be selected for execution, but would they > work? > > I have taken another look on the code now, it looks like with the absence of > jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be > good to skip this test altogether if there is no jdk.zipfs available. > > Shura > >> On May 25, 2016, at 10:49 AM, Xueming Shen <xueming.s...@oracle.com> wrote: >> >> >> 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 >> >
