Re: leak in gnu.bytecode.ZipLoader

[Thomas Kirk <tk at research dot att dot com>]

 > But it should get closed when the ZipLoader is finalized.  Are you
 > keeping lots of ZipLoader instances around?  I designed ZipLoader for
 > the case where you normally only keep a few instances around.  Still,
 > I can see that if you call (load "...zip") many times, and each time
 > one or two clases don't get loaded, there could be a problem.
 > 

I'm not doing anything (that I'm aware of) to hold onto the ZipLoader
instances, but it is clear that something is holding onto them.
One possibility: since a Class holds a pointer to its ClassLoader,
perhaps the class isn't being reclaimed, so the loader never becomes 
garbage. 

but even if there was nothing preventing the ZipLoader from being GC'd,
this error could potentially occur many times before finalization
cleans it up, so it's not clear that it's a good idea to rely on the
GC to take care of this. in the extreme, one might not be aware this
is happening until the process hits its limit of open file descriptors.


 > My ideal solution:
 > 
 > * Keep the default as is - i.e. the archive isn't closed until either
 > all classes have been loaded, or the ZipLoader is finalized.
 > * Add a 'loadAll' method, which loads all classes that haven't been loaded
 > yet, but without calling resolveClass.
 > * Add a 'closeZip' method which closes the underlying ZipFile.  Also add
 > logic to re-open the ZipFile if needed by a subsequent loadClass.
 > * Have loadCompiled call the 'loadAll' method.


This seems like a fine solution (modulo my disagreement about relying
on finalizations to clean up, but I can live with that).