ZipFileSystem doesn't obey spec of newOutputStream()

[Colin Decker]

On Wed, Feb 12, 2014 at 7:42 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 11/02/2014 21:21, Colin Decker wrote:
>
>> The spec states that newOutputStream(), given no OpenOptions, behaves as
>> if CREATE, WRITE and TRUNCATE_EXISTING were provided. ZipFileSystem (or
>> ZipPath more specifically) instead uses CREATE_NEW and WRITE. Is there some
>> reason for this?
>>
> It shouldn't be using CREATE_NEW and I suspect just an oversight in the
> original implementation of this provider. I've created this bug to track it:
>
> https://bugs.openjdk.java.net/browse/JDK-8034773
>
>
>
>> Another question: ZipFileSystemProvider's newFileSystem(Path, Map) method
>> throws UnsupportedOperationException unless the Path is a default file
>> system path. I can't really see a good reason for this. Certainly, there
>> could be some file systems it doesn't work well with, but other file
>> systems it may work fine with. It seems to work more or less perfectly with
>> my in-memory file system under JDK8. I was actually able to work around
>> this behavior of ZipFileSystemProvider by having my own FileSystemProvider
>> implementation return a ZipFileSystem from its newFileSystem(Path, Map)
>> method, by appending "jar:" to the Path parameter's URI and calling
>> newFileSystem(URI, Map). It seems sort of wrong, but it works.
>>
> The zip provider should work with other file system providers. I remember
> Philippe Marschall identified and provides a patch for one issue
> (JDK-8004789) and that is fixed in JDK 8.
>
> Can you expand a bit on the problem you are seeing and does it only arise
> when there is a problem open JAR or zip files that don't have .zip or .jar
> extension?


Yeah, I recall the other issue being fixed. The specific thing I'm talking
about is line 134 here:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/43386cc9a017/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java

There, ZipFileSystemProvider will only create a new ZipFileSystem from a
Path if that Path is associated with the default file system. So
FileSystems.newFileSystem(myZipFilePath, null) throws UOE unless
myZipFilePath is associated with the default file system. *Unless* some
other FileSystemProvider takes it upon itself to implement
newFileSystem(Path, Map) in such a way that it creates a "jar:" URI and
passes it to FileSystems.newFileSystem(URI, Map), which works but is really
a hack since ZipFileSystemProvider should really at least try to create a
ZipFileSystem regardless of what FileSystem the Path comes from.


>
> -Alan.
>
>
>


-- 
Colin Decker | Software Engineer | cgdecker at google.com | Java Core
Libraries Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140212/f25261a1/attachment-0001.html