classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Small ZipFile patch


From: Jeroen Frijters
Subject: RE: Small ZipFile patch
Date: Tue, 4 Mar 2003 23:16:56 +0100

Mark Wielaard wrote:
> 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.

Yep. You can do some very tricky things with this. For every non-final
class with a non-final finalize it is possible to obtain an initialized
reference to an instance of that class *without* running a constructor
by taking advantage of the fact that the finalizer runs even if the
constructor was never invoked.

> 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?

Yes, you're right, ignore the patch, I'll fix my VM.

> > 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. 

In that case the spec is broken. I really don't have a problem with it
being there, but I just want to point out that it is really bad design
to do anything in a finalizer other than releasing native resources. If
ZipFile is implemented using RandomAccessFile which uses FileDescriptor
which has a finalize, the FileDescriptor finalize may run before the
ZipFile finalize and thus the close will fail (unpredictably). This is
why it is bad design.

Regards,
Jeroen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]