No. I don't think so. Memory management in Java is entirely automatic. There are statements available like "System.gc();" but even that only suggests to the JVM that running the garbage collector might be a good idea. Whenever a variable goes out of scope it loses all its references and is liable to garbage collection, but the garbage collector comes round whenever it sees fit. There have been posts on these fora suggesting that producing several thousand other objects to fill up memory encourages the garbage collector to sweep memory. The unpredictability of collection is why one so rarely uses the finalize() method.
On a related note though, you can deterministically call a close() method, if there is one, to free up external resources. This is typically best done with a finally clause, e.g.
As Campbell said, you really can't control when the memory is freed, not reliably. But you can at least deterministically free up other resources. That's not what you asked, but I think it's as close as Java comes to what you want. Take it or leave it, I guess...
Memory is but one kind of resource (albeit an important one). There are other kinds of resources - database connection, file handles, mutex locks etc.
Using methods on each of the objects of those classes in the finally block to "terminate" those resources is transferring the responsibility of their destruction from the author of these classes to the client users of the classes.
Joined: Jan 30, 2000
[Anand]: Using methods on each of the objects of those classes in the finally block to "terminate" those resources is transferring the responsibility of their destruction from the author of these classes to the client users of the classes.
Well, the client (who created the object) is responsible for determining when it should be closed. The author of the class is responsible determining how.
So, do you still have some sort of question here? The answer to your first was no.
Easy question: no. There is absolutely no way to express "delete this object now" in Java. This is by design. Other languages make other choices, but unless we're designing a new language, there's no point in discussing the merit of this decision.
Well, there *is* an idiom for "when you've opened foo, you also need to close it when you are done" that can be transferred to Java from other languages, although it becomes a little bit clumsy on the way. And it isn't in any way implemented in the standard API.
If that were implemented for file input streams, for example, you could then write
And you could be sure that the inputstream *always* is closed correctly. (Or rather, if not, there is a bug in the File class.)
The syntax is much nicer in other languages such as Smalltalk, Ruby or even C#, as far as I know. And checked exceptions can really get in the way of this idiom. Still a good trick to know. [ September 03, 2006: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 30, 2000
Yeah - it's certainly not a widespread idiom in Java (which was Anand's initial question), but it is catching on somewhat. I think the convoluted syntax will severely limit its use in the Java community. However there is a proposal to add closures to java which would alleviate this. If it goes through (big if, and it could take a while) then this sort of idiom may become much more common.
Note that compilers frown on using keywords like "do" as method names , so the Closure interface above should probably have a different method name, e.g. use() or perform().
Also, yes Anand, the technique shown only handles the close(), not freeing the memory. Deterministic object destruction remains impossible in Java, as EFH said. Aside from the nondeterministic nature of Java's GC, note that nothing prevents the code in do() (or whatever the name is changed to) from saving a reference to the Foo instance somewhere, thereby preventing garbage collection of the Foo after doWithFoo() completes. So there are still ways programmers can create memory leaks here if they're careless (or evil) enough. But reliable calling of close() is nice, bettter than nothing anyway. [ September 03, 2006: Message edited by: Jim Yingst ]