• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

using finalize() to save data?

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(I hope I picked the right forum for this question...)
I am wanting for an object (of a class I am writing) to be able to save the values of its variables to a file before it goes away, regardless of whether the "driver" program saves anything... would there be any drawback to doing this in the object's finalize() method?
 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paula Davis:
(I hope I picked the right forum for this question...)
I am wanting for an object (of a class I am writing) to be able to save the values of its variables to a file before it goes away, regardless of whether the "driver" program saves anything... would there be any drawback to doing this in the object's finalize() method?


using the finalize method for anything critical is not a good idea. you don't know when finalize() will be called, if at all. This is from the JVM specification (the JLS says it as well, i just had this handy):
"The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused. Nor does the language specify which thread will invoke the finalizer for any given object. If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates."
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html
 
Paula Davis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Jon. Please bear with me as I ask for clarification on your reply.

"The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused. Nor does the language specify which thread will invoke the finalizer for any given object. If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates."


Yes, I read the same thing in the tutorial on Sun's web site. However, I took that to mean simply that (1) you can't count on the exact timing and (2) if anything you are doing in finalize() might cause an exception, you had better catch & handle it within finalize() because it will not get caught anywhere else further up the line. However, from your response I gather that the execution is more dicey than that? Can you give me specifics on the background behind your warning not to do anything important in finalize()? Is this "I've really been burned this way" or is it "Mmmm, not sure but I wouldn't try it if I were you"? I realize that the bottom line is that there would always be a chance that data might be lost, even with try/catch blocks in the finalize() method... but how great is that chance? If it is a rare distant chance of occasional glitches, it might be worth it in this case, because *occasional* loss of data in this case would be a nuisance but not a catastrophe. On the other hand, if losing data would likely be a common occurrence with this approach, then the nuisiance factor becomes enough to make it worth whatever contortions are necessary in order to save the data some other way.


you don't know when finalize() will be called, if at all.


"If at all?" This *sounds* inconsistent with the above quote, "it will happen before the storage for the object is reused"--would you clarify this for me? Is it a fact that "finalize()" may not be called at all, or was that hyperbole? I am not asking this in order to nit-pick your answer; I just want to be clear on what my options are, and the possible/likely outcomes, before I make a decision.
And my final question:


use the
However, it is also a question for general/future reference, because this is the first time that I have had occasion to want to use finalize().
Thanks.
Paula

 
Paula Davis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OOPS! It looks like I had a little snag with the [CODE] tags I'm still learning what I can and can't do in controlling the appearance of posts here in the saloon. Sorry.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Is it a fact that "finalize()" may not be called at all, or was that hyperbole?


It's a fact. See the last part of this JavaWorld.com article
Re UBB, you need to close the CODE tag with [/CODE]
 
Jon Dornback
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paula,
good questions, and i'll answer them as best I can (others wiser than me may be able to answer better).
The finalize() method is a good feature of the language. But, it's generally recommended to be used as "clean up", not as performing any actual logic. So, finalize() is good for things like closing database connections, closing sockets, etc. I've never heard of it being used for actual program logic (eg saving data). This isn't to say it *can't* be used like that, just that it normally isn't.
As Junilu confirmed, the finalize() method is not guaranteed to run, and if it hits an exception it just stops execution. So, in your case, the data may never be saved if the finalizer doesn't run. Or, potentially worse, if finalize() starts to execute, and then throws an exception of some sort, it may leave your data half-written (meaning that if other programs depend on that data, they might have trouble parsing it). of course, this is probably no worse a scenario than writing data anywhere else in a program.
I'd recommend calling a method that explicitly saves the data instead of relying on finalize(). I think it's better programming practice, but I'd welcome thoughts from other ranchers on this.
Jon
ps - the note about the code tags is just my signature. many times people post code samples without using the UBB formatting, and it is very hard to read. sorry for the confusion!
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Paula]: This *sounds* inconsistent with the above quote, "it will happen before the storage for the object is reused"
There's no inconsistency. It's guaranteed that IF an object is GC'd - that is, if the GC process is completed and the memory for that object is made available for other objects to be created - THEN the finalize() method must have been called before the GC process completed. Note I said called - if an exception is thrown before finalize() completes, well, the method was still called, it just didn't finish. The other big loophole is that there's no guarantee that any given object ever will be GC'd. If it's GC'd, finalize() will be called first; if it's not GC'd, finalize() may not be called. It's also possible that the GC process is started but not completed for that object - maybe finalize() is called, but the object can't be collected afterwards (perhaps because finalize() created a new reference that prevents collection). Or maybe someone calls System.exit() or hits control-C before collection can complete. Too much in the GC process is outside our control - there are some guarantees, but not enough to make finalize() reliable for most applications.
[ May 30, 2003: Message edited by: Jim Yingst ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic