Which java keyword cannot be used inside the body of a static method?

Which java keyword cannot be used inside the body of a static method, but may be used without problems in a non-static method?
[133 byte] By [Lukas_Adamek] at [2007-11-26 12:03:45]
# 1
thisI hope you score well on the test!
comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 2

> 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();

}

}

sabre150 at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 3
It doesn't make sense to use this is a static method...No 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.
YodaOfDarkness at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 4

> 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.

comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 5

> 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!

sabre150 at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 6

>(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

YodaOfDarkness at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 7

> 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.

comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 8
> 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).
comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 9

> > 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.

comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 10

> 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).

YAT_Archivist at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 11
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.
jwenting at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...
# 12

> 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.

comstevebrecher at 2007-7-7 12:29:18 > top of Java-index,Java Essentials,Java Programming...