Question

Often, I come across code where the Getter method is repeatedly used/abused to get some value or pass it as a method parameter, for ex:

public class Test {
   public void someMethod() {
      if(person.getName() != null && person.getName().equalsIgnoreCase("Einstein")) {
           method1(person.getName());
      }
      method2(person.getName());
      method3(person.getName());
      method4(person.getName());
   }
}

I usually code it, as below:

public class Test {
   public void someMethod() {
      String name = person.getName();
      if(name != null && name.equalsIgnoreCase("Einstein")) {
           method1(name);
      }
      method2(name);
      method3(name);
      method4(name);
   }

In my opinion, there is considerable memory/performance advantage in assigning the getter to a variable and using it, as Getters are Java methods and use stack frames. Is there really a considerable advantage in coding that way?
}

Answer 1

Have you profiled your opinion lately.

Performance:

This might have been a micro-optimization that was something to be concerned with in 1999-2001 in a pre-1.2 JVM and even then I would have questioned it unless some serious numbers showed otherwise.

Modern JIT implementations would tell you that today that your opinion is out of place.

Modern compiler implementations do all kinds of optimizations that make thinking about things like this a waste of time in Java. The JIT just makes it even more of a waste of concern.

Logic:

In a concurrent situation, your two code blocks are not logically equivalent, if you want to see changes, making the local copy will prevent that. Depending on what you want to do, one or the other approaches could create very subtle non-deterministic bugs that would be very hard to pin down in more complicated code.

Especially if what was return was something mutable unlike a String which is immutable. Then even the local copy could be changing, unless you did a deep clone, and that gets really easy to get wrong really quickly.

Concern yourself with doing it correctly, then measure and then optimize what is important as long as it doesn’t make the code less maintainable.

The JVM will inline any calls to final instance members and remove the method call if there is nothing in the method call other than the return this.name; It knows that there is not logic in the accessor method and it knows the reference is final so it knows it can inline the value because it will not be changing.

To that end

person.getName() != null && person.getName().equalsIgnoreCase("Einstein") 

is expressed more correctly as

person != null && "Einstein".equalsIgnoreCase(person.getName())

because there is no chance of having a NullPointerException

Refactoring:

Modern IDE refactoring tools remove any arguments about having to change code in a bunch of places as well.