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 >
