.method() without reference

Question

I've noticed that the following code compiler properly in my program:

ArrayList<Token> eval = new ArrayList<>(0);
for (Token token : tokens) {
 eval.add(token);
 if (token.equals(new Token("EOS", "EOS"))) {
 .clear();
 } else {
 continue;
 }
}

But, the part .clear() confuses me. I should be doing instance.method(), but .method() works too! Why is this?

• markspace: For "bare methods" like this, the this keyword is assumed. I.e., it's this.clear(); Although normally you don't use a dot at the beginning. Hmm.
• ZhongYu: No it does not compile.
• hyperneutrino: It compiles in my case, but only under this context. Strangely enough, when I remove the if... else... statement and only put .clear(), it will not compile.
• kajacx: @JamesSmith what compiler/IDE do you use? I have Eclipse with Java 8, and it doesn't compile. You probably have some additional tools that compile this otherwise uncompilable source.
• hyperneutrino: I use Eclipse. I have not modified any of the settings. I use Java 8. Eclipse LUNA.

Answer 1

The snippet in your question is syntactically incorrect. The following syntax applies to method invocation expressions

Method Invocation

 - MethodName ( [ArgumentList] )
 - TypeName . [TypeArguments] Identifier ( [ArgumentList] )
 - ExpressionName . [TypeArguments] Identifier ( [ArgumentList] )
 - Primary . [TypeArguments] Identifier ( [ArgumentList] )
 - super . [TypeArguments] Identifier ( [ArgumentList] )
 - TypeName . super . [TypeArguments] Identifier ( [ArgumentList] )

In other words, you can use the identifier (name) of the method, unqualified, where the context will determine what method that is and what its target reference is (if it has one). Otherwise, you'll need an expression or type name that prefixes the method identifier with a . character. Again, there are a set of rules that determine the method being invoked, at compile time and run time.

This part of your code

.clear();

does not fit the syntax defined above. It is, if used literally in the source, syntactically incorrect in Java.

You might be looking at pseudo code or an abridged form of the language (within an IDE, for example).

• hyperneutrino: No, I wrote the code myself with actual Java, and it showed no compilation errors. But regardless, a thorough answer. +1
• Sotirios Delimanolis: @JamesSmith Provide something complete and reproducible. You can also try compiling it on ideone.

Answer 2

Here's a quote from the JLS

15.12.1. Compile-Time Step 1: Determine Class or Interface to Search

The first step in processing a method invocation at compile time is to figure out the name of the method to be invoked and which class or interface to check for definitions of methods of that name. There are several cases to consider, depending on the form that precedes the left parenthesis, as follows.

If the form is MethodName, then there are three subcases:

If it is a simple name, that is, just an Identifier, then the name of the method is the Identifier.

If the Identifier appears within the scope of a visible method declaration with that name (§6.3, §6.4.1), then:

If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.

This search policy is called the "comb rule". It effectively looks for methods in a nested class's superclass hierarchy before looking for methods in an enclosing class and its superclass hierarchy. See §6.5.7.1 for an example.

So if the method name is a simple identifier (just a name), it looks in your class first, then super classes. If not found, then it looks for enclosing classes. Last, it looks for static imports.

Normally you don't need all of this info since you shouldn't have three or four methods to choose from. That's hard on a maintainer. But you should be aware of the search order, because sometimes name conflicts do occur, and you should be at least aware that there is a defined search order. The important rule to remember is your class first, then super classes. The other two are pretty intuitive.