ClassLoader

[Per Bothner]

Kresten Krab Thorup <krab@gnu.org> writes:

> The question is how to do this the best way.  I'd actually prefer if
> the jar file would not have to be written to the file system at all.
> It seems like it would be sufficient to have an in-memory
> representation, and let swapping take care of the rest.  The problem
> is, that there is no such thing as a RandomAccessByteArrayFile, or the
> like.  So this is not realy a viable option.

But you could define one ...  RandomAccessFile is not a final class.

A clean model might be to define a RandomAccess interface.  However,
that might be difficult to do without breaking the existing class
hierarchy, which would violate compatibility.  However, internally
RandomAccessFile could/should be implemented as something that
forwards to a "peer" (by analogy with awt).  There would be a default
peer that uses the file system, but we could have a hidden
constructor that allows you to specify a specific peer.  Or we could
go one level deeper:  Have File forward all requests to a FilePeer
class.  For teh problem at hand (an in-core Jarfile), create (with
a private constructor) a File that uses a ByteArrayFilePeer, and pass
that to the ZipFile constructor.  That passes it on to the
RandomAccessFile constructor, which ends up using the ByteArrayFilePeer.

In this model a ByteArrayInputStream is basically a FileInputStream
that was created using a ByteArrayFilePeer ...

The problem with taking this model too far is that it is difficult
to do while maintaing both binary compatibility and efficiency.
Adding extra indirections in the common case (i.e. for standard
classes) is not desirable.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/