zipfs and write support

[Alan Bateman]

Joel Uckelman wrote:
> I have what I believe is a functioning thread-safe read-write zipfs
> implementation now---at least it passes all the tests I wrote---
> subclassed from the existing zipfs classes. My question now is whether
> it would be better to fold that code into the original read-only zipfs 
> classes, or to keep the read-only and read-write versions separate.
>
> One thing I don't know is whether there will be much of a performance
> hit in using the read-write version for reading only. I implemented 
> locking in the simplest possible way, with a ReadWriteLock, so it 
> supports shared reads but exclusive writes. As a result, if you're
> only reading, there should never be any lock contention, so I don't
> expect this to cause much overhead. (The way which would permit for
> greater concurrency, locking on subtrees instead of having one lock
> for the whole ZIP archive, is a bit more work, so I held off on that
> for now.)
>
> Thoughts?
>   
It sounds like you've made good progress. If it extends the existing zip 
provider then I assume it must still be based on java.util.zip, right? 
Have you given any thought to access from others VM or applications? 
It's hard to comment on the locking without more information - if there 
a file opened for writing then does it block all other (read) access to 
the "file system"?

-Alan.