In Java, what is the difference between this.method() and method()?

Question

Is there any difference between calling this.method() and method() (including performance difference)?

Answer 1

The only time it matters is if you are using OuterClass.this.method() e.g.

class OuterClass {
    void method() { }

    class InnerClass {
        void method() {
            OuterClass.this.method(); // not the same as method().
        }
    }
 }

Answer 2

There is absolutely no difference between these constructs and the generated bytecode will be exactly the same, hence no performance impact. this is resolved during compilation if not explicitly defined.

The only reason for using explicit this is readability - some people find it easier to read because this suggests that this is an instance method of current object.

Also please note that if method() is static, using this is discouraged and misleading.

private static void method() {
}

private void foo() {
    this.method();    //generates warning in my IDE for a reason
}

And in this case it will also have no effect on performance.

Answer 3

That there is no difference can be seen by calling javap -c ClassName on the commandline. For example:

public class This {
    private void method() {
    }
    public void noThis() {
        method();
    }
    public void useThis() {
        this.method();
    }
}

Produces the following disassembled output:

Compiled from "This.java"
public class This extends java.lang.Object{
public This();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public void noThis();
  Code:
   0:   aload_0
   1:   invokespecial   #2; //Method method:()V
   4:   return

public void useThis();
  Code:
   0:   aload_0
   1:   invokespecial   #2; //Method method:()V
   4:   return

}

Answer 4

For methods there is no difference, but it can make a difference with fields. Consider this code:

private String someObject = "some value";

public String someMethod(String someObject) {
     //this.someObject refers to the field while
     //someObject refers to the parameter
}

Answer 5

There is no real difference - At least there is no performance impact. I prefer not writing "this" - The IDE can usually highlight calls to this anyway, and I think it is less readable when every access to methods/fields/... start with "this.". But it really is a matter of personal preference.

Answer 6

There is no difference at all other than the readability. It makes it more clearer to the reader.

Answer 7

Use this.method() and/or this.myVar or don't - on methods there is no difference, on vars there may be - but be consistent about it. I see it sprinkled throughout code, sometimes I even see this.m_myClassVar.

Personally I prefer to prefix my class vars with a simple underscore and put a trailing underscore on my method args:

public MyClass
{
    private int _myInt;

    public void myMethod(final int myInt_, final int fooFactor_)
    {
        _myInt = myInt_ * fooFactor_;
    }
}

Although most IDEs will make it clear which is which, I find this tends to prevent misassignment and makes the intentions of the code clearer and IMO easier to read.

I do use _thisInstance.myMethod() (where _thisInstance is a reference to the outer class) or _thisInstance._myVar, in inner classes/listeners/threads/etc. where I need to be clear about what method on which class I am calling and/or where I need to have a reference to a class instance.

Answer 8

Using this.method() makes clear that a function associated with the instance of the class is being invoked, as opposed to a static function or one belonging to another object.

It's in the spirit of those C++ developers who like to prepend "m_" on all member variables in a class. It makes ownership unambiguous. I tend to like it, but it's not as important when you're using an IDE that clarifies such things using colors and fonts.

Answer 9

Have you tried to do this.variable in the constructor?

In theory, in C++, since the object has not yet been created there is no this. I am not sure of the case in Java.