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