best way to call methods in a class

[Suman Mummaneni]

Hi guy,
I have class from which I have to call methods can you confirm which are the best way to do it.
Class A and B are classes available

  
Class A {
   public B test() {
     ///do some complex things and create new objects
   }
}
 
Class B {
    public void doB() {
     ///do some thing
    }
}
 
/////////////////////// Example 1
Class MyClass {
    public void testA() {
      A a = new A();
      B b = a.test();
      b.doB();
      .....
      .....
      b.doB();
      
    }
}   
////////////////////////// Example 2
Class MyClass 2 {
     public void testA() {
       A a = new A();
       a.test().doB();
       .....
       .....
       a.test().doB();
     }
}

[steve souza]

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 ]

[Suman Mummaneni]

Hi Steve,
I think following the example 1 we would have to explicitly set the value to null to start garbage collection once the variable is not used. But this is still a style issue

[steve souza]

That is a local variable, and so is very short lived. Assigning a null to the object is definitely a case of premature optimization.

[Suman Mummaneni]

Well you are right in one case its a local variable. But the method may not exit soon depends on the processing that method has to do. We might need to do a GC some times before we can exit a method.

[Jim Yingst]

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.

[steve souza]

I'd rethink my design before depending on nulling out an object to trigger it to be garbage collected.

[Ben Bos]

I just happened to come across this conversation. I am not a seasoned programmer, but doesn't garbage collection only operate on heap memory?

[Jim Yingst]

[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.