This is primarily a style issue, not a performance issue.
One advantage of assigning to a temporary variable (B b = a.test()) is that if you step through a debugger you can explictly see the variables value. Another advantage in my opninion is that if you call one method on an instance and later add calls to other methods the approach above looks cleaner (vs repetitive calls to a.test().doB()). If you did the second approach you would have to change existing code if you switch to (b.doB()) approach, however you wouldn't have to change existing code if you did the opposite switch.
Also, in some cases by assigning to a temporary variable you can make it clear what the particular instance will be used for. Here is an example.
A a = new A(); MyClass colorHolder=a.getHolder(); Color color=colorHolder.get(i);
That is more descriptive (though less abstract) than the following:
A a = new A(); Color color=a.getHolder().get(i);
Note also you can get a null pointer exception in this case if getHolder() can return a null.
Having said that I am consistent in doing this myself, so I would be interested in hearing advantages/disadvantages from others. [ March 27, 2008: Message edited by: steve souza ]
There may be rare cases where this makes a significant difference, but in general it's a waste of time to null out local variables. I wouldn't bother with it unless I had evidence that it made a difference in the particular case I was dealing with. Local variables just don't last long enough to make it worthwhile. And as of JDK 6, escape analysis means that many objects referenced by local variables will be cleared automatically when the method exits anyway, without waiting for regular GC. It's better to just keep the code simple and concentrate on the important things, letting the JIT and GC handle the details that they're good at.
"I'm not back." - Bill Harding, Twister
Joined: Jun 26, 2002
I'd rethink my design before depending on nulling out an object to trigger it to be garbage collected.
I just happened to come across this conversation. I am not a seasoned programmer, but doesn't garbage collection only operate on heap memory?
Joined: Jan 30, 2000
[Ben]: doesn't garbage collection only operate on heap memory?
Yes, but local variables can prevent garbage collection as long as the method (or block) has not completed yet. Steve and I are saying that this effect is pretty unimportant, since methods always come to an end eventually, usually pretty quickly, so any delays in GC due to local variables are usually fairly minor.
Also, as of JDK 6 some objects may be stored on the stack rather than the heap. This is generally only done if the JIT can determine that object is only referenced from within the method that created it, and therefore it is guaranteed that when the method completes, the object is no longer needed. One could argue that this is a form of garbage collection, and it uses the stack rather than heap. Basically, as of JDK 6, you often won't know for sure whether an object is on the stack or heap, and you're generally better off not worrying about it.