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

Is there a difference between the calls to this.method() and method() (including the performance difference)?

+43
java methods
Jul 01 '11 at 11:22
source share
9 answers

The only time this is important is if you use OuterClass.this.method() , for example.

 class OuterClass { void method() { } class InnerClass { void method() { OuterClass.this.method(); // not the same as method(). } } } 
+58
Jul 01 2018-11-11T00:
source share

There is absolutely no difference between these constructs, and the generated bytecode will be exactly the same, therefore, there will be no performance impact. this allowed at compile time unless explicitly defined.

The only reason to use explicit this is readability - some people find it easier to read because this assumes this is an instance method of the current object.

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

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

And in this case, it also will not affect performance.

+27
Jul 01 2018-11-11T00:
source share

That there is no difference can be seen by calling javap -c ClassName on the command line. 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 } 
+18
Jul 01 '11 at 11:35
source share

There is no difference for the methods, but it can make a difference for the 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 } 
+5
Jul 01 2018-11-11T00:
source share

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

+2
Jul 01 '11 at 11:25
source share

There is no difference other than readability. This makes it more readable to the reader.

+2
Jul 01 2018-11-11T00:
source share

To use this.method() and / or this.myVar or not - there is no difference on methods, it can be on vars - but be consistent in that. I see that he sprinkled all the code, sometimes I even see this.m_myClassVar .

Personally, I prefer to prefix my vars classes with a simple underscore and put the final underscore in my method argument:

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

Although most IDEs will make it clear exactly what, I find that this tends to prevent misappropriation and makes it easier to read code intent and IMO.

I use _thisInstance.myMethod() (where _thisInstance is a reference to an outer class) or _thisInstance._myVar , in inner classes / listeners / threads / etc. where I need to clearly indicate which method I'm calling and / or where I need to have a reference to an instance of the class.

+2
Jul 05 2018-11-11T00:
source share

Using this.method () makes it possible to understand that a function associated with an instance of a class is called, unlike a static function or a function belonging to another object.

This is in the spirit of those C ++ developers who prefer to add "m_" to all member variables in the class. This makes the property unique. I like this, but it’s not so important when you use the IDE, which clarifies such things using colors and fonts.

+1
Jul 01 '11 at 11:27
source share

Have you tried making this.variable in the constructor?

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

-2
Jul 03 2018-11-11T00:
source share



All Articles