 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006Disposing of an object?
The title may be a little off topic actually but anyway... I have an application which every time an XML file is opened creates an instance of a class called XMLParser. This does not extend any other classes and it's function is to validate the XML file and retrieve all the required data from it and store it in arrays/hashmaps. If the user were to close the file, how long does the instance of XMLParser exist for? Is it disposed of automatically as long as no references to it exist or do I have to actually dispose of it manually? The reason I ask is that should the user open a second XML file after closing the first, another instance of XMLParser is created, with the new arrays holding the new data. When the other classes within the aplpication need to access the data would they not get confused between the first instance of XMLParser and the second? Bearing in mind they will be identical apart from the data stored within the arrays etc? So basically, how do I ensure that the first instance of XMLParser no longer exists or is no longer accessible when a second instance is created? Thanks Steve On Sat, 25 Mar 2006 15:49:11 +0000, Stephen Marjoribanks <s.j.marjoribanks@durham.ac.uk> wrote, quoted or indirectly quoted someone who said : >If the user were to close the file, how long does the instance of >XMLParser exist for? Is it disposed of automatically as long as no >references to it exist or do I have to actually dispose of it manually? Presuming any references to the old one are null or are replaced by references to a different object it will hang around until you run out of RAM. There will be a GC pass and all live objects will be scavenged leaving any dead ones behind and their space reclaimed. See http://mindprod.com/jgloss/garbagecollection.html It is considered more hip to create a new object even when the old one will do. Why? Presumably because in recycling there might be some slip in initialisation. Perhaps it is just an unconscious accommodation to consumer culture.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Sat, 25 Mar 2006 15:49:11 +0000, Stephen Marjoribanks > <s.j.marjoribanks@durham.ac.uk> wrote, quoted or indirectly quoted [quoted text clipped - 9 lines] > leaving any dead ones behind and their space reclaimed. See > http://mindprod.com/jgloss/garbagecollection.html Is this still the case if both the 'old' and 'new' objects are called the same though? For example in my code, when the user opens a file the code XMLParser parser = new XMLParser(); executed. If the instance of XMLParser 'parser' is still hanging around (even if it is not in use anymore) and a new instance also called 'parser' is created (by executing the line of code above again) how will it know which 'parser' to reference? > It is considered more hip to create a new object even when the old one > will do. Why? Presumably because in recycling there might be some > slip in initialisation. Perhaps it is just an unconscious > accommodation to consumer culture. In my case, I guess I have done it for conveniences sake. Creating a new object just means that I don't have to write some more lines of code to clear out all of the arrays/hashtables within the object! Thanks Steve ... >> Presuming any references to the old one are null or are replaced by >> references to a different object it will hang around until you run out [quoted text clipped - 12 lines] > 'parser' is created (by executing the line of code above again) how will > it know which 'parser' to reference? This may be clearer with a shift in mental model of what the line of code says. It does not mean "Create an XMLParser and name it 'parser'". It means "Declare a reference variable, scope from here to the end of the current block, named 'parser' and initialized with a pointer to a new XMLParser". In Java, objects don't have names, so it does not make sense to think of "the instance of XMLParser 'parser'". A reference variable does have a name and is either null or a pointer to some object, so while 'parser' remains in scope, it does make sense to think of "the XMLParser that variable 'parser' currently references". Patricia > This may be clearer with a shift in mental model of what the line of > code says. [quoted text clipped - 10 lines] > > Patricia Ah yes, ok thank you, I think this was a missing part in my understanding of Java! Steve On Sat, 25 Mar 2006 17:25:49 +0000, Stephen Marjoribanks <s.j.marjoribanks@durham.ac.uk> wrote, quoted or indirectly quoted someone who said : >XMLParser parser = new XMLParser(); > >executed. If the instance of XMLParser 'parser' is still hanging around >(even if it is not in use anymore) and a new instance also called >'parser' is created (by executing the line of code above again) how will >it know which 'parser' to reference? If you write XMLParser parser = new XMLParser(); ... parser = null; theXMLParser object is a candidate for garbage collection. If you write: parser = new XMLParser(); You have a second XMLParser object pointed to. Nobody presumably is pointing to the old one any more. So the old one is subject to garbage collection. If somebody else is pointing to it, it won't be GCed. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Sat, 25 Mar 2006 15:49:11 +0000, Stephen Marjoribanks > <s.j.marjoribanks@durham.ac.uk> wrote, quoted or indirectly quoted [quoted text clipped - 14 lines] > slip in initialisation. Perhaps it is just an unconscious > accommodation to consumer culture. Also because in many cases the "optimization" of keeping a cache of reusable objects around performs worse than letting the GC do its job. And also because a reusable object is ipso facto mutable, making it more dificult and error-prone to use. On Sat, 25 Mar 2006 18:17:49 GMT, "Mike Schilling" <mscottschilling@hotmail.com> wrote, quoted or indirectly quoted someone who said : >Also because in many cases the "optimization" of keeping a cache of reusable >objects around performs worse than letting the GC do its job. That is if you keep your own pool of recycled objects. That is different from simply reusing the object you already have. I think in all cases reusing should be faster. The only case I can see where the opposite would be true is if you held on to a an object you no longer needed on hopes of recycling later. Often you would be better off to let it go, uses its ram for ether purposes, and create a new one when you needed it. It is a bit like the decision you make to rent or own a tent. Much of the time though you are creating an object identical to the one you are freeing. The main reason then is to recycle you need a different mechanism than the constructor for initialisation, which might not work exactly the same way. Ideally there would be a way to exactly reproduce the constructor logic on a recycle. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. If there are no references to an object, that object is no longer accessible. It just stays in limbo until the garbage collector destroys it. > The title may be a little off topic actually but anyway... I have an > application which every time an XML file is opened creates an instance of [quoted text clipped - 16 lines] > longer exists or is no longer accessible when a second instance is > created? No offense meant, Stephen, but you need to find a good introductory Java book and read the sections on classes, objects, and garbage collection. These are the among the most basic concepts of the language, and until you master them, you'll have a difficult time programming in it. >No offense meant, Stephen, but you need to find a good >introductory Java book and read the sections on classes, >objects, and garbage collection. Or: just read about objects and classes and forget about garbage collection. Eventually, one will need to learn something about garbage collection indeed, but it is not urgent. >>No offense meant, Stephen, but you need to find a good >>introductory Java book and read the sections on classes, [quoted text clipped - 5 lines] > Eventually, one will need to learn something about garbage > collection indeed, but it is not urgent. The details of its operation can probably wait, but the fact that it exists is important, especially for someone coming from C++ who's wondering about object deletion and destructors. > No offense meant, Stephen, but you need to find a good introductory Java > book and read the sections on classes, objects, and garbage collection. > These are the among the most basic concepts of the language, and until you > master them, you'll have a difficult time programming in it. No offense taken! I did read a number of Java books and I'm sure I did read about this but my mind went blank yesterday and I got confused! I am only a newbie to Java ;-) Steve > The title may be a little off topic actually but anyway... I have an > application which every time an XML file is opened creates an instance > of a class called XMLParser. This does not extend any other classes and > it's function is to validate the XML file and retrieve all the required > data from it and store it in arrays/hashmaps. Others have replied with useful info, and to that I would just like to add: There is a certain method you can call - System.gc() - to indicate that you would like the JVM to consider doing a garbage collection. It's not actually guaranteed that the JVM will a garbage collection when you call this method - but regard it as a way of providing a request that garbage collection should happen. 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.