aspose file tools*
The moose likes Java in General and the fly likes Idioms for Deterministic destruction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Idioms for Deterministic destruction" Watch "Idioms for Deterministic destruction" New topic
Author

Idioms for Deterministic destruction

Anand Hariharan
Rancher

Joined: Aug 22, 2006
Posts: 257

C++ has determinstic destruction by default (what Stroustrup calls "RAII") and C# chose to overload the 'using' keyword for this purpose.

Are there any well established idioms in Java that enable a programmer to have deterministic semantics (i.e., when the object goes out of scope, so ends its lifetime) for his/her objects?

TIA,
- Anand


"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
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.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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...


"I'm not back." - Bill Harding, Twister
Anand Hariharan
Rancher

Joined: Aug 22, 2006
Posts: 257

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.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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.
Anand Hariharan
Rancher

Joined: Aug 22, 2006
Posts: 257

Originally posted by Jim Yingst:

So, do you still have some sort of question here? The answer to your first was no.


While I understand that the language does not provide support for deterministic destruction, I am trying to find out (as evinced by the subject of this thread) if there are idioms to achieve the same.

Are you saying there are no idioms to achieve this, as well?
[ September 02, 2006: Message edited by: Anand Hariharan ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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.


[Jess in Action][AskingGoodQuestions]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Idioms for Deterministic destruction
 
Similar Threads
"delete" in java
Why Functions Cannot be Nested
another sample question
how to create array using linked list....
Technical buzzword bingo