slightly OT: "Static member accessed via instance reference" Follow

You're ok as long as you can guarantee the reference will be non-null. But
it will always be a point of fragility in your code.
N.

Brad Lane wrote:

I know there is no point in accessing a static member from an instance
reference but is there any actual problems with doing this if you
already have an instance reference anyway? For example:

>

 anObject o = new anObject();
> int value = o.SOME_STATIC_MEMBER;
> ]]>

>

as opposed to:

>

 anObject o = new anObject();
> int value = anObject.SOME_STATIC_MEMBER;
> ]]>

It also harms code readability.

"Nathan Brown" <nedski@yahoo.com> wrote in message
news:bca05p$55a$1@is.intellij.net...

You're ok as long as you can guarantee the reference will be non-null.

But

it will always be a point of fragility in your code.
N.

>

Brad Lane wrote:

I know there is no point in accessing a static member from an instance
reference but is there any actual problems with doing this if you
already have an instance reference anyway? For example:

>

 > anObject o = new anObject();
> > int value = o.SOME_STATIC_MEMBER;
> > ]]>

>

as opposed to:

>

 > anObject o = new anObject();
> > int value = anObject.SOME_STATIC_MEMBER;
> > ]]>

>
>

90% of the time it's an error because you think you are affecting the instance variable and not the actual one. Here is one I find often


Thread t = new Thread(){
public void run(){
doSomething();
}
};

t.start();

t.yield(); //oops doesn't yield t, it yields current thread

or

t.dumpStack(); //oops dumps current thread stack not t's

You wrote:

1. nObject o = new anObject();

I would rather say:

1. aClass anObject = new aClass();

or

1. aClass aClassInstance = new aClass();

Then it makes more sense: a 'Class' is a 'factory' that makes 'objects' ('instance').

Static 'properties' (or 'members') and 'methods' are services that the 'Class' (the 'factory') provides, and that can be accessed from anywhere outside the Class, without having to instanciate an object from that class.

Therefore, for the sake of good object oriented design, it is recommended that static members are accessed via ClassName only, and not via instance.

I know you know all that, I just wanted to make a point ! ;)

Dan/

Thanks for a good real-life example !

The most screwy thing that can happen is when you have two classes that
have a same-named static field and one is a sub-class of the other.
Check the output of running the class below:

package test;

public class StaticTest {
public static class Base {
public static final String NAME = "Base";
}

public static class Sub extends Base {
public static final String NAME = "Sub";
}

public static void main(String[] args) {
Base baseInstance = new Base();
Sub subInstance = new Sub();
Base subInstanceAsBase = new Sub();
System.out.println(baseInstance.NAME); // prints "Base"
System.out.println(subInstance.NAME); // prints "Sub"
System.out.println(subInstanceAsBase.NAME); // prints "Base"
}
}

That and the fact that from an OO-purist standpoint statics are meant as
attributes of the Class itself and not the instances lead me to leave
the "Access static member via instance reference" in the IDE settings to
at least "As warnings". (I don't set it to "As errors" if it's a big
project where other people have done this a lot. I kind of save the
error marking for things that are VERY likely to be errors rather than
just bad ideas.)


~Mike

"Brad Lane" <_no_spam_brad.lane@pearson.com> wrote in
news:bc9vbn$37s$1@is.intellij.net:

I know there is no point in accessing a static member from an instance
reference but is there any actual problems with doing this if you
already have an instance reference anyway? For example:

 anObject o = new anObject();
> int value = o.SOME_STATIC_MEMBER;
> ]]>

as opposed to:

 anObject o = new anObject();
> int value = anObject.SOME_STATIC_MEMBER;
> ]]>

Thanks for all the answers. The only reason I asked is that I found some
code in our project (not my code of course:)), that is doing this and was
thinking of filing a bug on it. After reading all the posts and although I
don't think it's a problem now, I think it will be in the future.

Thanks again. This is why I love the IDEA community.


"Brad Lane" <_no_spam_brad.lane@pearson.com> wrote in message
news:bc9vbn$37s$1@is.intellij.net...

I know there is no point in accessing a static member from an instance
reference but is there any actual problems with doing this if you already
have an instance reference anyway? For example:

>

 anObject o = new anObject();
> int value = o.SOME_STATIC_MEMBER;
> ]]>

>

as opposed to:

>

 anObject o = new anObject();
> int value = anObject.SOME_STATIC_MEMBER;
> ]]>

>
>

You're ok as long as you can guarantee the reference will be non-null.

In fact it does no matter. As far as I remember according the the Java
Language Spec. the qualifier expression is even not evaluated (and
definitely not used). So it can be null. :)

--
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Nathan Brown" <nedski@yahoo.com> wrote in message
news:bca05p$55a$1@is.intellij.net...

You're ok as long as you can guarantee the reference will be non-null.

But

it will always be a point of fragility in your code.
N.

>

Brad Lane wrote:

I know there is no point in accessing a static member from an instance
reference but is there any actual problems with doing this if you
already have an instance reference anyway? For example:

>

 > anObject o = new anObject();
> > int value = o.SOME_STATIC_MEMBER;
> > ]]>

>

as opposed to:

>

 > anObject o = new anObject();
> > int value = anObject.SOME_STATIC_MEMBER;
> > ]]>

>
>

That's weird, I'm sure I read somewhere that since 1.4.something, calling a
static method from a null instance reference would fail, but I just tried it
and it worked. Can't remember where I read it either. Anyone have a clue?

N.

Valentin Kipiatkov wrote:
>> You're ok as long as you can guarantee the reference will be
>> non-null.
>

In fact it does no matter. As far as I remember according the the Java
Language Spec. the qualifier expression is even not evaluated (and
definitely not used). So it can be null. :)

>

--

>

"Nathan Brown" <nedski@yahoo.com> wrote in message
news:bca05p$55a$1@is.intellij.net...

>> You're ok as long as you can guarantee the reference will be
>> non-null. But it will always be a point of fragility in your code.
>> N.
>>
>> Brad Lane wrote:
>>> I know there is no point in accessing a static member from an
>>> instance reference but is there any actual problems with doing this
>>> if you already have an instance reference anyway? For example:
>>>
>>>

>> anObject o = new anObject();
>>> int value = o.SOME_STATIC_MEMBER;
>>> ]]>

>>>
>>> as opposed to:
>>>
>>>

>> anObject o = new anObject();
>>> int value = anObject.SOME_STATIC_MEMBER;
>>> ]]>

From http://java.sun.com/j2se/1.4.1/changes.html:

--

In addition, the null check is done for instance constants. For example, in the expression

x.y

where y is an instance constant member of x, we now check x for null and emit a null pointer exception when it is null.

--

So you do need to do a null check.

I'm stupid. That's not for static members. However, it does say:

--

Previous versions of javac used to discard the left-hand-side of a qualification expression when the right-hand-side is a constant or a static member. That is not correct according to the JLS. javac now correctly evaluates the LHS. Specifically, in an expression such as

x.y.z

where y is an instance field of x and z is a static field of y, the compiler used to omit the required null pointer check on x.

--

But that's not the same thing either. So no, I'm pretty sure now that you don't need a null check.

Ah thank you! Yes this was what I read, and it seems I also read it wrong
too the first time ;)

Cheers,
N.

Keith Lea wrote:

I'm stupid. That's not for static members. However, it does say:

>

--

>

Previous versions of javac used to discard the left-hand-side of a
qualification expression when the right-hand-side is a constant or a
static member. That is not correct according to the JLS. javac now
correctly evaluates the LHS. Specifically, in an expression such as

>

x.y.z

>

where y is an instance field of x and z is a static field of y, the
compiler used to omit the required null pointer check on x.