On Sat, 15 Sep 2001, Bojan Smojver wrote:
> Remy Maucherat wrote:
>
> > TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
> > directly (using JarFile objects). I'm really careful about properly closing
> > these objects when the CL is dumped when reloading. However, there are still
> > problems, at least under Windows (the symptoms are roughly what you
> > describe). So it looks like the problems are with the java.util.jar package.
>
> After playing a bit more with the whole thing, it turns out that there
> is an IOException thrown when bytes are read from
> java.util.zip.ZipFile$1 (I'm guessing 1 is an internal class in ZipFile
> which is actually an InputStream - do I see JDK people giving a nod?).
> The ZipFile object is brand new after jar gets refreshed and yet it
> seems to be reading something totally bogus data.
>
> One other somewhat interesting observation: if the jar grows, the class
> file cannot be found. If it shrinks, class is found but properties files
> packed in there are not. Really amusing...
Seems like a bug in JDK, if ZipFile is new it shouldn't use the old stuff.
It seems the ZipFile uses a native implementation... Can you try with a
different VM ? Maybe IBM 1.3 ( well, it can be identical ) ?
I think Ant has a good replacement for the whole zip, and we can certainly
take a look. Creating a class loader using the different zip is also
possilbe, and plugging it in is also easy.
However, I would mark this as LATER. The whole thing can take time, and I
don't think we can/should put this into 3.3 ( because it'll be new
untested code ).
Costin
