Code analyze

[alesj]

I went over the code and removed some redundant locale variable definitions, class casts, null initializers, small code optimizations, ...

I hope that's ok - or are those things intentional for some extra info?

[starksm64]

Why bother with such trivial changes, and what is the benefit of it? For all I know hotspot can remove these so I doubt there is any performance issue.

[alesj]

Hmm .. you're definitely right, as the hotspot code reducing goes.

Just asking if anyone is bothered by the change - I'm a minimalistic code person - so I don't want to step on anybody's toes.

[adrian.brock]

Certainly, in most cases, if the JIT can't optimize to a cpu register,
it will reintroduce the temporary anyway.
That is true even if you don't use a temporary in your code.

The optimization to a register (rather than a stack entry)
will be done regardless of whether the temporary is explicitly declared.

However, with most modern cpus it makes no real difference
since the memory (for smallish methods) will be cached on the cpu.
Making it nearly as fast as registers anyway.

I'd imagine that hotspot removes unncessary cases if it is JIT compiled?
If it is not JIT compiled then it doesn't need optimization.

But the unncessary cast does make the code harder to read.

[adrian.brock]

In general only make these changes if it improves the
readability/maintainability of the code.

e.g. removing dead/unnecessary code gives less to maintain
in future.

Removing temps doesn't change the semantics of the code
so it doesn't really change anything.
In some cases, temps are more optimal.

e.g. code that doesn't use a temp that should:

doSomething(getSomethingLotsOfWork());
doSomethingElse(getSomethingLotsOfWork());

Also temps are useful for tracking down NPEs.

object.getSomething().getSomethingElse();

should be

temp = object.getSomething();
temp.getSomethingElse();

So you know which part was null when you've only got the line number.