Two objects are being created (besides the BettyAck one): an integer object holding the value 10 and another one holding 99. Vars x and y refer to those objects respectivly. Doing y = null inside findOut doesn't change the original value of y, so you can pretty much ignore that method all together. When z comes into play it is made to "point" to the same object y does. So now x refers to the object with 10 and both z and y refer to the other one. After doing z = null, you still have x and y pointing to the objects. Both objects have a reference to them so they can't be collected.
Hi Mary, To a method you pass a copy of the value of the reference variable and not the actual object as if you where saying �findOut(y = x )�. Any manipulation of the referred object is �felt� outside of the method, but any change to the object reference variable like �y=null� is local and has no influence outside of the method. I�ll diverge a bit, hoping to make it more clear: Since the Integer wrapper class is immutable, I�ll change the scenario a bit to give an additional example. Suppose your method looked like 'public void findOut(final StringBuffer y)', then you could have been changing the object y in the method findOut, but you wouldn�t have been allowed to change the reference variable with y = null. hth, Cheers, Gian Franco [ April 20, 2004: Message edited by: Gian Franco Casula ]
Hey.. just noticed that we almost had the same name.. This is NOT related to java.. but.... uhmmm... . . . Person me = new Person("Gianfranco Alongi"); Person yu = new Person("Gian Franco Casula"); return me.equals(yu); . . Which we know is false..
Faster machines are a bad excuse<br />for writing unoptimized code<br />Like java...
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com