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.
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.
might not be called if the process dies. In Java, the framework is
try/finally, and that has the same potential problem. However, it is