> But there's a fine balance here. You want to discourage people from using
finalizers (or java.lang.ref) when there's another reasonable alternative.
But you don't want to make finalizers so unusable that they use unreasonable
alternatives instead.
>
> (I consider any technique that basically involves reimplementing a garbage
collector in client code, e.g. by reference counting, to be unreasonable.
And sometimes, rarely, that's the only other option.)
>
> Hans
I agree that we want to discourage people from using finalizers. I disagree
with your characterization of "unreasonable".
I say that people *do* need to implement another garbage collector. But they
are not *reimplementing* _the_ garbage collector, because _the_ garbage
collector is a garbage collector for *heap space*, I repeat, *heap space*
(not objects or files or anything, just heap records. A heap record is not
an object. A heap record is something that might be used at some point to
store some part of an object maybe perhaps.) So when you want to collect
file descriptors or other native resources, you need another garbage
collector--you can't use a heap space garbage collector to collect garbage
file descriptors. Doesn't that sound logical?
So if we want to provide a feature in Java that makes it easier for people
to collect their garbage native resources, that's okay with me. But don't go
dragging the heap space garbage collector into this, because it doesn't have
anything to do with it.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT