Alan.Bateman at Sun.COM
Sun Oct 18 12:26:56 PDT 2009
Joel Uckelman wrote:
> I've been looking at the zipfs demo and have noticed some problems:
> * The HashSet ZipFileSystem.closeableObjects could be modified from two
> different threads if each thread calls ZipFilePath.newInputStream() or
> newByteChannel() at about the same time.
> * Closeables are only removed from ZipFileSystem.closeableObjects when
> the ZipFileSystem is closed. This means that closed streams and channels
> will stick around long after they could otherwise be gc'd.
> * ZipFileSystemProvider.fileSystems has concurrency problems similar to
You are right and there are concurrency issues here. Also all returned
closeables should be wrapped so that close method removes them from the
set. Rajendra, do you have cycles to fix this?
(Joel - as background, the zip provider is a demo provider that was
developed to exercise/test the provider mechanism. It needs a bit of
work to turn it into a robust provider)
> * Should ZipFileSystemProvider.newFileSystem() really return two distinct
> FileSystem objects when called with two different env Maps?
I don't see a problem here as the newFileSystem methods are required to
return a new file system (irrespective of the entries in the map). Note
that it's okay for several FileSystem instances to share access to the
underlying zip file and this can be transparent to the user of the API.
More information about the nio-dev