Juraj wrote:No, you don't. At least not if you know what you're doing.jverd wrote:Yes I choose static vs. non-static for performance reasonJuraj wrote:It's unlikely that that's true to any significant degree. Most likely your test is flawed. In addition, you do NOT choose static vs. non-static for performance reasons.
I have made a test and the non-static methods are faster than static
EDIT: In fact, if there were a measurable difference, I'd expect static method invocation to be slightly faster, since it's compile-time bound.
Edited by: jverd on Apr 8, 2009 8:47 AM
BigDaddyLoveHandles wrote:Hindsight is a great thing.deepak_1your.com wrote:By definition a utility class has all static methods. So as soon as you mention "utility class" you've already made a decision. The real question is "should method X be static or non-static"? My default position is to assume no method should be static, and then wait to be convinced.
Sorry mate... did not get that.
Look at utility class java.lang.Math, for example. It has static methods sin(), cos(), sqrt(), etc... An obvious choice for a utility class, right? Then they introduced class StrictMath in 1.3 with exactly the same static method signatures. That's a code smell that one should have written an interface and implemented it in at least two ways, but it's too late for that because the original methods are static.
Juraj wrote:Presumably after automated profiling the entire application under a load that mimics a real production load.
Yes I choose static vs. non-static for performance reason