Re: finalize() overhead

Eric Sosman wrote:
Joe Seigh wrote:
[...]
At the metalevel, there seems to be a curious disconnect here. How are
non-memory resources less important than memory resources? If some C++
type showed up and claimed that RAII and explicit deallocation of
memory was good enough and GC wasn't necessary, they'd be flamed out of
existence. But requiring explicit deallocation of non-memory resources
is ok somehow, or at least not an important problem.

There's no implication that non-memory resources are in
any way less important. If anything, the implication is the
reverse: Non-memory resources can be too important to leave to
the mercy of a garbage collector ignorant of their significance.

The language has built-in support for managing memory but
lacks support for automatic management of database connections,
floating-license token reservations, font caches in the video
card, and on and on. Perhaps Java's inventors felt that a general
framework for managing such an open-ended list of resources was
desirable (I said "perhaps," right?) but intractable.


They seem to be using it themselves. See java.io.FileInputStream
docs and source.



It could be argued that the destructor is just such a
framework. I'm not well versed enough in language design to
make a convincing argument either way, and perhaps the argument
belongs on an advocacy group anyhow. But for whatever reason,
Java does not have automatic destructors, and people who seize
on finalize() as a destructor substitute are doing themselves
no favors.


It's not a substitute. I never said anything about using it instead
of explicit resource clean up. It would be there for the exact same
reason java.io uses it.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software. .

Relevant Pages

  • Re: finalize() overhead
    ... non-memory resources less important than memory resources? ... But requiring explicit deallocation of non-memory resources ... framework for managing such an open-ended list of resources was ... on finalizeas a destructor substitute are doing themselves ...
    (comp.lang.java.programmer)
  • Re: finalize() overhead
    ... non-memory resources less important than memory resources? ... But requiring explicit deallocation of non-memory resources ... framework for managing such an open-ended list of resources was ... on finalizeas a destructor substitute are doing themselves ...
    (comp.lang.java.programmer)
  • Re: IDisposable with managed code
    ... Mark wrote: ... IDisposable allows you some control over when ... non-memory resources are released: ... etc. IDisposable has no effect upon when the GC will reclaim memory. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: finalize() overhead
    ... the finalize() method itself is a hint. ... They hurt memory usage. ... But requiring explicit deallocation of non-memory resources ...
    (comp.lang.java.programmer)