tags:

views:

193

answers:

7

I'm working with Java; I have worked with C++ before. I am thinking about static usage in Java. If I create static methods and variables in the class, Why can I access them through the object also?

Example:

class Test{
  static int count=0;
  int id;
  static void updatec(){
    count++
   }
}

class TestMain
{
   public static void main(String args[])
   {
         Test.count=1;
         Test t = new Test();
         t.count=5; // Valid WHY ?????
   }
}

Why this is allowed? Java's site says we should not use obj.static method/variable.
Why it is allowed?

+1  A: 

You shouldn't doesn't mean you can't.

Anyway, this is allowed in C++ also.

klez
"You can, doesn't mean you should", perhaps?
Michael Mrozek
Yes, also that.
klez
+7  A: 

Static doesn't mean that the field is only for the class. It means it for the class and all its instances.

In this example, the class variable origin of the class Point is referenced both using the class name as a qualifier, in Point.origin, and using variables of the class type in field access expressions (§15.11), as in p.origin and q.origin. These two ways of accessing the origin class variable access the same object, evidenced by the fact that the value of the reference equality expression (§15.21.3):
q.origin==Point.origin is true

But you're right it's usually a bad idea to refer to a static field/method/class from a non-static context, it can confuse the developer.


Resources :

Colin Hebert
Well done; I was starting to seriously worry about the answers on this question
Michael Mrozek
Yes, and I believe that was a mistake. It's far too easy to call a static method thinking it was an instance method and get unexpected behavior.
R. Bemrose
Let's say we have a `Car` class. And `color` is a static field. i don't need to know that all cars are blue to get the color of any car. With this you can refer to a static field without having to know that the field is static. It's not a good practice, but still it's true that my car is blue.
Colin Hebert
While technically true, it is quite simple to use Point.origin for clarity in most cases.
Peter DeWeese
Hmm, I feel if its not encouraged than why its legitimate statement. javac should give error . Why its not done in that fashion!
asb
Because even if it can be misunderstood, it still true. This is semantics.
Colin Hebert
+2  A: 

There is no good reason why this is allowed. It's confusing and it serves no purpose. Good tools will warn you about this (or maybe even give you the option to fail compilations over it). But it is part of the language and so it will never be taken out because that would break existing code.

jjujuma
A good tool will fail your compilation over something that's expressly allowed in the language?
Michael Mrozek
a good tool will warn you that it makes more sense to access `ClassName.staticField` rather than `instance.staticField`
matt b
@Michael Mrozek -- well, maybe not. I've toned it down. I would choose this in a tool I used because if I referred to a static member through an instance, it could *only* be because I had misunderstood something.
jjujuma
But running on the console using javac will not give any warning.
asb
+3  A: 

It's legal to access static fields through an instance, although you'll generally get a warning about it. The field is still static, however, so there's only one per class:

     Test t = new Test();
     Test u = new Test();
     t.count = 5;
     System.out.println(u.count); // Outputs 5
Michael Mrozek
No warning on bare console:(.
asb
+1  A: 

Your snippet is perfectly legit, either in Java or C++ equivalent.

It seems you're confusing access restriction (private, protected, public) and instance/class distinction for members (static keyword).

Since you have an instance of class Test (named t) in your static main method, you can use instance methods/members of class Test, that's conforming with the documentation you quoted.

If the count field was private or protected, you wouldn't be able to access it, but that would have nothing to do with static.

jv42
A: 

static in this case means there's one shared instance per class, not per instance. So when you change t.count, you're changing the 'count' member for the whole class and ALL instances.

That is, these will print the same value:

System.out.println(t.count);
System.out.println(Test.count);

There's nothing illegal about it, although it's usually not a great idea because it looks like instance data.

ianmclaury
+1  A: 

It really should not have been supported. This support leads to this dubious code in org.apache.commons.cli command-line parser.

class OptionBuilder

public static Option create();
public static OptionBuilder withLongOpt(String newLongopt);
public static OptionBuilder withDescription(String newDescription);

This leads to this:

Option opt =
  OptionBuilder
    .withLongOpt( "opt" )
    .withDescription( "opt description" )
    .create( );

It would be much better and cleaner and thread-safe, if there were a default OptionBuilder constructor and all static methods were instance methods. That's the model used by StringBuilder/StringBuffer

Alexander Pogrebnyak