You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bojan Smojver <bo...@binarix.com> on 2001/09/18 13:08:24 UTC

[PATCH]: TC 3.3: DependClassLoader

After digging some more into the code of it, I've realized that the
readFully() method is really hard to understand. So, unless there are
some substantial performance gains in the existing approach, maybe we
should go with something a bit simpler.

And just as a side note, you've probably noticed that I've produced some
simple code to replicate (alleged) JDK ZipFile bugs. Any feedback on the
validity of that code would be welcome (ie. maybe I'm doing something
really stupid in there).

Bojan

Re: [PATCH]: TC 3.3: DependClassLoader

Posted by Bojan Smojver <bo...@binarix.com>.
cmanolache@yahoo.com wrote:
> 
> Hi Bojan,
> 
> First, you're a commiter now, feel free to fix anything you see
> broken :-)

Didn't know it was official. Thanks!

> Regarding this particular fix - it will not have a big performance
> impact ( except for loading .class files, which happen once ).
> However I would rather keep the old code and add comments -
> reading a stream byte-by-byte is not a good idea in any case.

OK. The patch I submitted was just a sample of a simplification.
ByteArrayOutputStream can be used with byte arrays. I'll submit one
patch along those lines.

I'll also comment the existing code (as I see) it and submit another
patch.

The only reason I would opt for ByteArrayOutputStream is simplicity. It
is obvious that designers of that class had this kind of use in mind, so
why duplicate the effort.

> I'll take a look at ZipFile.

Thanks, that's great. I'm having a few discussions with one guy at Sun
about it and he's giving me a bit of a red tape on it... But I'll get my
message across (hopefully).

Bojan

Re: [PATCH]: TC 3.3: DependClassLoader

Posted by cm...@yahoo.com.
Hi Bojan,

First, you're a commiter now, feel free to fix anything you see 
broken :-)

Regarding this particular fix - it will not have a big performance
impact ( except for loading .class files, which happen once ).
However I would rather keep the old code and add comments -
reading a stream byte-by-byte is not a good idea in any case.

I'll take a look at ZipFile.

Costin

On Tue, 18 Sep 2001, Bojan Smojver wrote:

> After digging some more into the code of it, I've realized that the
> readFully() method is really hard to understand. So, unless there are
> some substantial performance gains in the existing approach, maybe we
> should go with something a bit simpler.
> 
> And just as a side note, you've probably noticed that I've produced some
> simple code to replicate (alleged) JDK ZipFile bugs. Any feedback on the
> validity of that code would be welcome (ie. maybe I'm doing something
> really stupid in there).
> 
> Bojan