 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007Object reference counting
I think the answer is no, but is there any way for me to know how many Objects reference a given Object? The given object contains a reference to a disk file, and I'd like to delete the file when there are no more threads that reference the Object. In other words, when the Object is available for garbage collection, I want to get rid of the file. I think finalizers were intended for this purpose, but there is quite a bit out there on why using finalizers is a bad idea. > I think the answer is no, but is there any way for me to know how many > Objects reference a given Object? [quoted text clipped - 6 lines] > I think finalizers were intended for this purpose, but there is quite a > bit out there on why using finalizers is a bad idea. No. Java does not use reference counting, so the info is simply not there. I would suggest a pair of increaseCounter and decreaseCounter methods and a coding convention to use them. Arne Chris wrote: >> I think finalizers were intended for this purpose, but there is quite >> a bit out there on why using finalizers is a bad idea. Use of finalize() is not a bad idea. Misuse of finalize() is a bad idea. - Lew > Use of finalize() is not a bad idea. Misuse of finalize() is a bad idea. It is probably a bad case here. If the only requirement were that the file should be deleted, then it could be done just before the program exits. As soon at the requirement is that the file should be deleted as soon as it is not used, then the usage of finalizer is not good. Arne Lew wrote: >> Use of finalize() is not a bad idea. Misuse of finalize() is a bad idea. > It is probably a bad case here. I agree. My hero, Joshua Bloch, covers this well in _Effective Java_. "Use" of finalizers would be as a non-time-critical just-in-case guard for the release of resources, or to tie JNI manual garbage collection to Java automatic garbage collection. "Misuse" would be to rely on finalize() to release resources, rather than to explicitly release them (e.g., through "close()"). - Lew >I think the answer is no, but is there any way for me to know how many >Objects reference a given Object? [quoted text clipped - 6 lines] > I think finalizers were intended for this purpose, but there is quite a > bit out there on why using finalizers is a bad idea. Yes. The main problem in this case is that you're not guaranteed that the finalizer will run before the program exits. However, if you combine it with java.io.File.deleteOnExit(), you may be close to what you want. > I think the answer is no, but is there any way for me to know how many > Objects reference a given Object? [quoted text clipped - 6 lines] > I think finalizers were intended for this purpose, but there is quite a > bit out there on why using finalizers is a bad idea. It appears that you want to use the C++ RAII idiom in Java. Unfortunately, its not possible. First off, Finalizers are not destructors. There is no guarantee that an object will be freed, there is certainly no guarantee that its finalizer method will be called, so either way would result in your files staying around after the application stopped. Because of this, you have to design in a different way of managing your resources. The typical approach is for your class to have an explicit method (e.g. closeResource() or deleteFile(), etc). Andrew > no guarantee that its finalizer method I realize that this is picky, but not as picky as the compiler, but it's the "finalize()" method, not the "finalizer" method. - Lew > > no guarantee that its finalizer methodI realize that this is picky, but not as picky as the compiler, but it's the > "finalize()" method, not the "finalizer" method. > > - Lew :) A very late entry but... The Picky Award for 2006 winner is.... On Dec 30, 2:56 pm, Lew <l...@nowhere.com> wrote: >> I realize that this is picky, but not as picky as the compiler, >> but it's the "finalize()" method, not the "finalizer" method. > :) > > A very late entry but... > > The Picky Award for 2006 winner is.... This may tilt the voting: I was wrong. "finalize()" is the method that implements the "finalizer". Everyone uses the term, including my hero, Joshua Bloch. So I was anal and mistaken. - Lew > On Dec 30, 2:56 pm, Lew <l...@nowhere.com> wrote: > [quoted text clipped - 12 lines] > > - Lew yeah...but too late now... Pick up your award at the door ;-) >> no guarantee that its finalizer method > > I realize that this is picky, but not as picky as the compiler, but it's > the "finalize()" method, not the "finalizer" method. Be sure to tell SUN about it too ! I count numerous usages of the term "finalizer" in http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.6 Arne Lew <lew@nowhere.com> said: >> no guarantee that its finalizer method > >I realize that this is picky, but not as picky as the compiler, but it's the >"finalize()" method, not the "finalizer" method. Hmm.. given that we're talking about method named "finalize()", that performs finalizing actions, I have no problems calling in "finalizer method" in the prose form - as in: 'In Java, the finalizer method is called "finalize()".' Did I win the final? :-)  SignatureWolf a.k.a. Juha Laiho Espoo, Finland (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++ "...cancel my subscription to the resurrection!" (Jim Morrison) >> no guarantee that its finalizer method > > I realize that this is picky, but not as picky as the compiler, but it's > the "finalize()" method, not the "finalizer" method. At one point in the codebase I'm currently working on, I discovered: class .... { public void finalizer() throws Exception { .... } } I kid you not! -- Adam Maass Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.