Hi Gary,
Aren't you concerned that your giant-pile-of-code will behave incorrectly
due to the fact that a File embedded in a Zip can't implement most of the
File API properly? For anything but the most trivial pile I'd be pretty
worried about unintended, or even damaging, behavior.
On Thu, 13
PROTECTED]
Sent: Friday, November 14, 2003 07:27
To: Jakarta Commons Developers List
Subject: RE: [vsf] WAS: [general] Zip file proxy?
Hi Gary,
Aren't you concerned that your giant-pile-of-code will behave incorrectly
due to the fact that a File embedded in a Zip can't implement most
. Jonker [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 07:27
To: Jakarta Commons Developers List
Subject: RE: [vsf] WAS: [general] Zip file proxy?
Hi Gary,
Aren't you concerned that your giant-pile-of-code will behave incorrectly
due to the fact that a File embedded in a Zip can't
PROTECTED]
Sent: Thursday, November 13, 2003 13:39
To: Jakarta Commons Developers List
Subject: Re: [vsf] WAS: [general] Zip file proxy?
Subclassing io.File makes me rather uneasy. Most of its methods just
doesn't make sense for virtual files like those inside an archive.
Even basic stuff like getPath
I've done exactly this in Seedling (a HiveMind-ish application platform).
My first attemp using java.io was exceptionally painful. It's currently
implemented in via an abstraction layer called ConfigTree, from which
you can get URLs, from which you can open a stream. Implementations of
the
I'm not a developer of [vfs], only a user, but having
seen the source code for the File class, it's not worth
the effort to subclass. Most people anyway make assumptions
when they see a File object (as they should). One of the
basic assumptions is that they can pass it to a FileReader
or
