ZipFileSystem doesn't obey spec of newOutputStream()

Colin Decker cgdecker at
Wed Feb 12 08:52:07 PST 2014

On Wed, Feb 12, 2014 at 7:42 AM, Alan Bateman <Alan.Bateman at>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:
>> 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:

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 | Java Core
Libraries Team
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the nio-dev mailing list