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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath