> > RAII should be built in as it is in e.g. C++.
>
> In C++ RAII only works for objects on the stack. IMO,
> deterministic resource management is the desideratum - for
> stack- and heap-objects. But we will see this feature only
> in the successor of both, Java and C++.

RAII works by creating handles to objects and placing those handles on the stack. The objects being managed are often on the heap, in shared memory (in which case the handle must use an inter-process reference counting mechanism) or may have nothing at all to do with memory (e.g., semaphores and file locks). The end result is deterministic resource management.

Now that I've worked with C# some, I think there's a lot to be said for C#'s "using" blocks. However, I think that for the most part a garbage collector that knows about more than just memory would be perfectly fine. For instance, a garbage collector that allowed the user to (1) register file descriptors, (2) state that there is a maximum of XX file descriptors available, and (3) request garbage collection whenever open file descriptors reach 80% or more of the limit. This would be the same collector that would run if available memory fell too low or if some other resource became constrained.

In the event that the garbage collector runs and is not able to free up file descriptors, then the garbage collector would essentially be saying that all open file descriptors are being used by live objects. If there are no more descriptors (or memory, or ...) available, there isn't much to do except wait for some of those objects to die or determine if you're in a deadlock. But there wouldn't be much to do in an alternate world with an alternate system.

Sorry, I clicked the "post message" button to early.

the access method would look something like the this:

class DerivedResource {
//...
public void access(ResourceAccess ra) {
CloseableResource rs = null;
try {
rs = new CloseableResource();
ra.access(rs);
} finally {
if(rs != null) {
rs.close();
}
}
}
}

The whole acquiring and closing mechanism is delegated to DerivedResource now.
That way, thare's no way to forget to close the resource. Another advantage is that the boiler plate closing routine does not get duplicated over and over in the project.
If you've ever had the pleasure to fix hundreds of occurrencies of all possible variants of closing resources, you'll probably value that approach.