Forums Register Login

Calling static method [ Object vs Class ]

+Pie Number of slices to send: Send
Hi, I have been making sense of the call to a static method through the Class containing the method Vs the object instance of the class. Apart from the obvious logical reason, I would like to know whether any difference lies in the manner the compiler look at this.

I assume that compiler would resolve the call to the static method if through the Class at compile time and through object instance only at runtime.

Or it may so happen that the compiler is intelligent enough to resolve the call through Object instance at compile time.

Please share your thought.

+Pie Number of slices to send: Send
The proper way to call a static method is via the class. For example: -



For some reason that's lost to me, Java also allows you to call a static method via an object reference. It's the declared compile-time class of the reference that is used, not the run-time type of the object pointed-to by the reference. In fact, I think it works even if the reference is null (not sure, actually).

+Pie Number of slices to send: Send
Ouarf. That one is great :
+Pie Number of slices to send: Send
So what it means is that my program will have no (performance) sideeffects by using either approaches :roll:


In this case there is no valid reason why you should be allowed to access class variables and methods using the object reference. Doesn't make any sense.
+Pie Number of slices to send: Send
When you use a class ref. on the static method, then object of the class will not be created. Which means there is no use of heap memory. Which implies the fact that there is going to be a perf. issue. The reason why you have static methods is to enhance perf.
+Pie Number of slices to send: Send
 

Originally posted by sathishj:
The reason why you have static methods is to enhance perf.



No it isn't. Not 99.99% of the time anyway. The additional cost of an instance method over a static method is absolutely tiny.

Do you have a real-world example where you can show that there was a significant performance benefit to using static methods compared to instance methods? I'd make a small wager you don't.

Static methods are for operations that don't obviously belong to a particular object, but need implementing somewhere. They are good for "utility" methods, "factory" and "one-per-JVM" types of operation, although such things can often be sensibly done with instance methods too.

Liberal use of static methods is to be discouraged - it is not good Object-Oriented Design. It can make code difficult to re-use, because assumptions about there being only one of something may not be valid in the place where they're being re-used.
+Pie Number of slices to send: Send
 

Originally posted by Pradeep Kadambar:
So what it means is that my program will have no (performance) sideeffects by using either approaches :roll:




It actually will compile to exactly identical byte code, as far as I know.
+Pie Number of slices to send: Send
 

Originally posted by Ilja Preuss:



It actually will compile to exactly identical byte code, as far as I know.



I too think the same way.

Just before the compilation process gets over , the javac has something like the byte code optimization (might be something vendor specific , out of JSL specification).After this stage both might result in same byte codes.
+Pie Number of slices to send: Send
So this will be right if i say that Java guys having put the feature of calling static methods/variables using the object reference is logical faux pas
+Pie Number of slices to send: Send
 

Originally posted by Rahul Bhattacharjee:

Just before the compilation process gets over , the javac has something like the byte code optimization (might be something vendor specific , out of JSL specification).After this stage both might result in same byte codes.



There's no "maybe" about it, nor is it an optimization. By definition, calling a static method on a reference variable means calling the static method on the declared class of the reference variable. The compiler generates the same bytecode on the first pass.
+Pie Number of slices to send: Send
 

Originally posted by Pradeep Kadambar:
So what it means is that my program will have no (performance) sideeffects by using either approaches :roll:


In this case there is no valid reason why you should be allowed to access class variables and methods using the object reference. Doesn't make any sense.



Indeed, there is no valid reason why it should be possible to call static methods via an object reference. In my opinion the designers of the Java language made a mistake by allowing this. Java has been designed by humans and isn't 100% perfect...
+Pie Number of slices to send: Send
 

Originally posted by Jesper Young:

Indeed, there is no valid reason why it should be possible to call static methods via an object reference.



Well, in fact I can imagine a reason - that way you can declare a method static when it's already being used, without getting tons of compile time errors.
+Pie Number of slices to send: Send
 

Originally posted by Ilja Preuss:
Well, in fact I can imagine a reason - that way you can declare a method static when it's already being used, without getting tons of compile time errors.



Ok, but so what, there's nothing wrong with forcing people to keep their code clean; that will make their code easier to understand and maintain, cleaning it up immediately is probably cheaper in the long run. And if you're using a good IDE with built-in refactoring tools (like Eclipse), the IDE can automatically change the calls for you.

Calling static methods via object references instead of via the classname is always bad, and confuses many people; many people think, because of this, that it's possible to override static methods just like non-static methods, but that's not the case.
+Pie Number of slices to send: Send
 

Originally posted by Jesper Young:
Ok, but so what, there's nothing wrong with forcing people to keep their code clean;



I actually think there *is* something wrong with *forcing* people.

cleaning it up immediately is probably cheaper in the long run. And if you're using a good IDE with built-in refactoring tools (like Eclipse), the IDE can automatically change the calls for you.



When I update a thirdparty library where a method changed from non-static to static, I actually don't have a need to change my code before I have to read it again - and then a simple warning and a quick fix, such as Eclipse provides, is just perfect.
+Pie Number of slices to send: Send
 

Originally posted by Ilja Preuss:
I actually think there *is* something wrong with *forcing* people.


OK, maybe the word "forcing" sounds a bit strong. But in my opinion it is also not OK if a programming language allows you to write strange, dubious code constructions; obviously with any non-trivial programming language you can write obfuscated code, but it would be better if the language would encourage good programming. (For that reason, "goto" in Java is a reserved word, for example, which won't ever be implemented).

Originally posted by Ilja Preuss:
When I update a thirdparty library where a method changed from non-static to static, I actually don't have a need to change my code before I have to read it again - and then a simple warning and a quick fix, such as Eclipse provides, is just perfect.


I understand, but how often does something like that happen (method in 3rd party lib going from non-static to static) - this is probably very rare. I think that the problems caused by allowing calling static methods via object references are a lot greater than the advantage it has for a niche case like this.
Good heavens! What have you done! Here, try to fix it with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 2240 times.
Similar Threads
static vs non-static methods
object Vs instance
Compiler vs. Runtime Errors
Can anyone explain executing at runtime vs compile?
hide vs override
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 03:35:29.