Alan.Bateman at Sun.COM
Mon Oct 19 04:23:06 PDT 2009
Joel Uckelman wrote:
> Actually, I've already done it for closeableObjects. The only issue I'm
> wondering aobut is whether to use Collections.synchronizedSet() or to
> build a Set wrapper for a ConcurrentHashMap.
A synchronizedSet should be fine. The other part to the fix is each
returned InputStream, SeekableByteChannel, DirectoryStream, etc. needs
its close method to remove the closeable from the set.
> I'll be sending in the contributor agreement when I get to the office
> tomorrow (I can't print at home), so I'll be happy to start sumitting
> patches then.
> I'm viewing this with the intention of adding the ability to write ZIP
> archives also. Having multiple FileSystem instances for the same archive
> and doing some writes with each one might lead to trouble. OTOH, maybe
> the place for ensuring that the state of the archive remains consistent
> is ZipFileStore---every FileSystem for the same archive could share one
> It's not clear to me what should happen if someone tries to open multiple
> streams or channels on the same archive entry. With a disk filesystem,
> there's nothing stopping you from opening a FileInputStream and a
> FileOutputStream on the same file at the same time. In some limited cases,
> it might not even be wrong, e.g., if you're reading from and writing to
> non-overlapping parts of a file. Various other pathological things are
> If you close() a read-write archive, that should cause whatever writing
> was done (by writing to the temporary file cache) to be written back to
> the archive---which could mean that if there are other ZipFileSystem
> instances for the same archive, then the archive will have changed out
> from under them. Whether this is a problem, I'm unsure at present. Maybe
> preventing this should just be the responsibility of the user? Hmm.
The zip provider is read-only because it is based on java.util.zip and
so don't have support for updating zip/JAR files (it would require
re-writing the entire zip file). I assume, if you are looking to add
update support then you're probably basing it on something else - is
As regards concurrency, then the simplest approach is opening a zip
entry for writing requires exclusive access to that entry. That would be
good start anyway.
Asynchronously closing the FileSystem requires that you have an
asynchronous close solution for each of the channel, streams, etc. that
might be open. The required behavior for channel is well defined but not
so for input/output streams. Closing a FileSystem should not impact
anything that is accessing the zip/JAR file via another FileSystem
instance. You'll likely need to use file-locking to coordinate access
with other entities on the system.
More information about the nio-dev