RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()

Xueming Shen xueming.shen at oracle.com
Wed May 25 17:49:54 UTC 2016

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?


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.shen at 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

More information about the nio-dev mailing list