Does Java support RAII/deterministic destruction?

Question

It's been at least 5 years since I worked with Java, and back then, any time you wanted to allocate an object that needed cleaning up (e.g. sockets, DB handles), you had to remember to add a finally block and call the cleanup method in there.

By contrast, in C++ (or other languages where object lifetimes are deterministic, e.g. Perl), the class implementor would define a destructor function that performs the cleanup whenever an object of that class goes out of scope. The advantage of this approach is that the user of the object can't forget to clean it up -- the destructor gets called automatically, even if an exception is thrown. This approach goes by the fairly awful name of RAII -- "Resource Acquisition Is Initialisation".

It's been my experience that doing things "the RAII way" has saved me a lot of mental overhead in terms of not having to worry about whether and when resource deallocations occur. We are considering using Java for a medium-sized project, and I'm wondering if some sort of deterministic destruction is among the many new features added to the language since I last looked at it. (I'm hopeful as my complaint that "Java has no RAII" was rebuked on this thread, but so far I haven't been able to find any details by googling.)

So if someone could point me to some introductory material on how to go about this in Java that would be great!

Answer 1

Nope. There is no facility for allocating Objects on the stack. Every Object is allocated on the heap and can outlive whatever block it was initialized in. Or it may be collected mid-block, depending on the vagaries of the all mighty Garbage Collector.

If you're working on the server, you might want to check out Java EE. It has nothing to do with RAII, but it does have a decent system for managing the life cycles of expensive objects like DB connections. Java EE 5 is actually pretty nice to work with for a lot of problem spaces.

Answer 2

The approach I take is to use a layered product (sometime a simple static method) which takes care of the resource allocation. You don't want this sort of resource allocation littering your program.

There are plenty of libraries which do this. It not something you should have to worry about in most cases.

Answer 3

There is a pattern that helps here. It's not as nice as destructor based RAII but it does mean that the resource clean-up can be moved to the library (so you can't forget to call it).

It's called Execute Around, and has been discussed here before.

Interestingly I see Jon Skeet chimed in on that thread, but he didn't mention it here - shame on you Jon - missed an opportunity for some rep points there!

BTW, while I'm glad Brian Harry (see Jon's comment, again) went to the lengths of writing the email that he did - and it obviously did reflect a lot of thought that went into the process - and I'm glad we did get "using" out of it in C# - I don't agree with all his conclusions. In particular, I don't see why, if we can have using, we can't have a way to mark a type as behaving that way without "using". Of course it constrains the usage - but so does "using" - and most of the time it's exactly what you want. The trouble with "using" is that the client code still has to remember to use it. With C++ style RAII it's a property of the type. An arguably bigger problem with "using", or more accurately with the Dispose idiom, is that it's a lot more complicated and error prone than most people realise to get right - mostly because of the potential for objects to be brought back from the dead.

Answer 4

EDIT: The answer below was written in early 2009, when Java 7 was very much still in flux.

While Java still doesn't provide guarantees around finalization timing, it did gain a feature like C#'s using statement: the try-with-resources statement.

---

No, Java hasn't changed at all in that respect. You still need to use try/finally.

There's been discussion of adding the equivalent of C#'s "using" statement (which is syntactic sugar over try/finally) to Java, but I don't think that's going to be part of Java 7 any more. (Most of the language improvements seem to have been dropped.)

It's worth understanding that there are reasons why deterministic destruction hasn't been implemented in Java and .NET in the form of a reference-counted garbage collector, by the way - that a) impacts performance and b) fails with circular references. Brian Harry wrote a detailed email about this - it's about .NET and it's rather old, but it's well worth a close read.