Your variable is only holding a reference to the String object. In each iteration you overwrite the reference and such remove the reference to the old object.

So your bad example is absolutely OK actually. If I understand you correctly the ’solution’ to your problem would be like this:

for(int i = 0; i < 10; i++) {
String msg = “We are at position ” + i;
System.out.println(msg);
// no need for ‘msg=null;’ since it is out of scope automatically?
}

In this case we used the variable properly. There is no need for ‘msg=null’ since the variable goes out of scope at the end of every iteration.

BUT: The compiler is not able to optimize anything. Because it can’t know if the String object is still referenced or not. Why? Because you used msg as a parameter to another method and objects are passed to other methods *by reference*. So if the compiler doesn’t check if println saves a reference to this String object somewhere it can’t optimize anything. (It could know actually if it would do an analysis of the whole program, but it doesn’t).
So the ’solution’ is absolutely equivalent to your example (probably even in compiled bytecode).

Your argument has a point though: There is a possible memory leak wrt local variables: If you have references to many or big objects in (living) local variables and call some long running functions or do other long lasting tasks these objects can’t be freed since the references are not freed.

BTW. the point you are trying to make is probably a valid one talking about C++, since the lifetime of (stack) objects is scoped.

The hot new optimization technique in compilers these days is called Single Static Assignment. The idea goes like this: you have an intermediate level representation of the code where you have an infinite number of registers- but each register can only be assigned a value once, when it’s first used. This sounds to me like functional programming, only what I call “variables” are here called “registers”. And I’m not the only one who thinks this. In effect, modern compilers first convert your program to a functional program, and then compile and optimize that.

So it’s no surprise to me that Java is fitting the same pattern. Because, at the end of the day, it’s about the computer being able to reason about the code. For an optimization to be applied, the compiler has to determine two things about a particuler chunk of code: 1) can the optimization be profitably applied, i.e. is the resulting code faster/less memory intensive/smaller/better than before applying the optimization, and 2) can the optimization be safely applied, i.e. is the behavior of the program still the same after the optimization is applied as it was before? Both of these require reasoning about the program.

There are other advantages to the computer being able to reason about the code, and not just humans. For example, we can set the computer to finding bugs in our code, or at least proving that certain wide classes of bugs don’t exist. And the more the computer can figure out on it’s own, the less we humans have to tell it. For example, what type a particular variable or expression has. Functional programming languages are consistently and repeatedly demonstrated to be among the most productive languages, in large part because so much of the specifics are left up to the computer.

So it’s no surprise to me that a more functional style of Java programming is more advantageous. The trend has been obvious for decades, the question is when will the industry wake up to this fact.