ZipFileSystem doesn't obey spec of newOutputStream()

[Alan Bateman]

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?

-Alan.