[EMAIL PROTECTED] wrote:
>
> 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 ) ?
Doesn't work with IBM as well.
> 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 ).
How about I write a little section in the release notes of 3.3 (or
whichever other document you think is appropriate) and tell everyone
about the findings, so that there is no confusion as to why it doesn't
work as expected.
In the meantime, I'm posting a bug into Sun's bug database. I'm not sure
how fast they really are about those issues, but it might not be worth
writing a whole lot of new classloaders if they can fix it reasonably
quick (provided it really is a bug in JDK, of course).
Bojan