> this
>
So the following is not legal?
public class Fred100
{
public static void main(String[] args) throws Exception
{
final Runnable fred = new Runnable()
{
private final String hello = "Hello World";
public void run()
{
System.out.println(this.hello);
}
};
fred.run();
}
}
> It doesn't make sense to use this is a static
> method...
>
> o matter how many times a static variable/etc. is
> instantiated, they all share the same "hello"
> message, making it worthless to try to single out one.
this is used in an instance method: the instance of Runnable. Its hello variable is not static. So the posted code is indeed a clever counterexample to my answer to the OP's question.
"static variable is instantiated" doesn't make sense to me.
> It doesn't make sense to use this is a static
> method...
The OP did not ask whether or not it made sense.
>
> o matter how many times a static variable/etc. is
> instantiated, they all share the same "hello"
> message, making it worthless to try to single out one.
We can argue this one if you want!
>(stuff)
>
> "static variable is instantiated" doesn't make sense
> to me.
I should have phrased that better...
Say you have a class you made, called ManyNames, which has a static variable name, and a method setName(String name).
If you create multiple ManyNames objects, and use the set method on one, it changes them all. There's no reason to use this because you can just use name by itself.
I was thinking static variables, not methods, my mistake :P
> Say you have a class you made, called ManyNames, which
> has a static variable name, and a method
> setName(String name).
>
> f you create multiple ManyNames objects, and use the
> set method on one, it changes them all. There's no
> reason to use this because you can just use
> name by itself.
Not only is there no reason, it's illegal -- it won't compile.
> > Not only is there no reason, it's illegal -- it
> won't
> > compile.
>
> Whoops -- it will generate a warning (at least by
> Eclipse's compiler).
But javac doesn't complain. So I was not partially wrong -- I was completely wrong.
> But javac doesn't complain. So I was not partially wrong -- I was completely wrong.
It's still better not to use the "this", though. When you explictly reference a static member via an instance reference (theFoo.bar or this.bar, as opposed to Foo.bar) the JLS requires a check that the reference is non-null. Clearly "this" is always non-null, but javac still puts in half of the check. Take the simple class public class Test {
static int field;
public void setField(int i) {this.field=i;}
public void staticSetField(int i) {field=i;}
}
and observe the bytecodes produced: $ javap -c Test
Compiled from "Test.java"
public class Test extends java.lang.Object{
static int field;
public Test();
Code:
0:aload_0
1:invokespecial#1; //Method java/lang/Object."<init>":()V
4:return
public void setField(int);
Code:
0:aload_0
1:pop
2:iload_1
3:putstatic#2; //Field field:I
6:return
public void staticSetField(int);
Code:
0:iload_1
1:putstatic#2; //Field field:I
4:return
}The JIT will get rid of it, but you may as well avoid the waste in the first place. (And if you really do want to check that the reference is non-null, do the check explicitly so that maintainers know it's intentional).
> The entire argument is flawed.
> In the given example "this" isn't actually used in a
> static block.
> It's used in a class defined in a static block, but
> used inside an instance method of that class and
> therefore not statically scoped towards its
> containing class.
Quite right, but it's still textually "inside the body of a static method." I think "inside the body" supports the "textually" modifier. Regardless, I think the language issue is clear and it's really just a question of whether the instructor who assigned the OP's question as homwork or on a test (which the OP may have heard indirectly and posted to give us a "puzzle") would be flummoxed by the example of use by an instance of an anonymous class within the body of the static method.