Jeroen Frijters ([EMAIL PROTECTED]) wrote: > > Jeroen Frijters ([EMAIL PROTECTED]) wrote: > > > BTW, the design of the 1.0 I/O classes is less than > > stellar. Since the > > > FileDescriptor class is the owner of the native resource, > > it should have > > > had a finalizer, instead of FileInputStream and > > FileOutputStream (for > > > some reason RandomAccessFile doesn't have a finalizer). I > > guess I should > > > be a bit mild in my criticism, finalizers weren't very well > > understood > > > back then... > > > > I am in the process of correcting this. > > My gripe really wasn't directed at the Classpath implementation, but at > the Sun implementation. How compatible do we want to be in this case? > Compatible and broken or a little less compatible and not so broken ;-)
I think we want to do the right thing. I believe it was you yourself who pointed out a condition whereby a FileInputStream closing the file descriptor in finalization could potentially lead to problems. Particularly since you can use the getFD() call to return a valid file descriptor that would suddenly get un-valid if your FileInputStream happened to be garbage collected out from under you. Better to let FileDescriptor handle its own finalization. Actually, its much better if the application manually closes the stream (which would close the underlying file descriptor) because there is no guarantee that anything will ever get garbage collected. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
