Re: Small ZipFile patch

[Aaron M. Renn]

Jeroen Frijters (address@hidden) wrote:
> > Jeroen Frijters (address@hidden) 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 (address@hidden) http://www.urbanophile.com/arenn/