Re: Small ZipFile patch

[Mark Wielaard]

On Tue, 2003-03-04 at 15:11, Jeroen Frijters wrote:
> Hi,
> 
> ZipFile has a finalizer (it shouldn't!) and that tries to close the
> RandomAccessFile, even the RandomAccessFile never was created, this
> causes an NPE during finalization, not a big deal, but since .NET 1.1
> decided to print these to the console, it's kind of distracting.

Ewh. That can only happen when the constructor threw an exception. Hmmm,
interesting fact that the finalizer is also called in such cases. Hadn't
realized that. It means that when finalize is called the Object could be
in some very unexpected state.

If it really helps you, we can install your patch. But it seems you have
a bit of a problem here in your VM. Finalizer are allowed to throw
exceptions and this should not cause such side effects as printing to
some stream. What happens in other cases in your VM? Wouldn't it make
more sense to encapsulate any java finalize() method (if an class
overrides the default one in Object) with something that catches any
exceptions so that the .NET runtime doesn't print them to some output
channel?

> ZipFile really shouldn't have a finalizer though (if you have a pure
> Java implementation). Only classes that own native resources should
> have finalizers.

Actually, it should have a finalizer since the spec says it has a
finalizer. And according to the spec that finalizer will call the
close() method of that object.It is easy to follow the spec here, I
don't think we shouldn't do it if it is so easy.  It helps people to
migrate from some proprietary implementation to our free one. 

> BTW 2, in gnu\java\nio\ServerSocketChannelImpl.java and
> gnu\java\nio\SocketChannelImpl.java both have method called
> finalize*r* and that probably should be finalize (although since these
> classes do not seem to own any native resources, they really don't
> need a finalizer).

Michael, could you look at this?

Cheers,

Mark