Java static imports

Question

Just by experiment I discovered that Java non static methods overrides all same named methods in scope even at static context. Even without allowing parameter overloading. Like

import java.util.Arrays;     import static java.util.Arrays.toString;  public class A {     public static void bar(Object... args) {         Arrays.toString(args);         toString(args);     //toString() in java.lang.Object cannot be applied to (java.lang.Object[])     } } 

I can't find anything about this in spec. Is this a bug? If it isn't, are there any reasons to implement language like that?

UPD: Java 6 do not compile this example. The question is - why?

Answer 1

The explanation is simple although it doesn't change the fact that the behavior is highly unintuitive:

When resolving the method to be invoked the first thing the compiler does is find the smallest enclosing scope that has a method of the right name. Only then come other things like overload resolution and co in game.

Now what is happening here is that the smallest enclosing scope that contains a toString() method is class A which inherits it from Object. Hence we stop there and don't search farther. Sadly next the compiler tries to find the best fit of the methods in the given scope and notices that it can't call any of those and gives an error.

Which means never statically import methods with a name that is identical to a method in Object, because methods that are naturally in scope take precedence over static imports (the JLS describes method shadowing in detail, but for this problem I think it's much simpler to just remember that).

Edit: @alf kindly submitted the right part of the JLS that describes the method invocation for those who want the whole picture. It's rather complex, but then the problem isn't simple either so that's to be expected.

Answer 2

It is not an override. If it did work, this.toString() would still access the method of A instead of Arrays.toString as would be the case if overriding had occurred.

The language specification explains that static imports only affect the resolution of static methods and types:

A single-static-import declaration d in a compilation unit c of package p that imports a field named n shadows the declaration of any static field named n imported by a static-import-on-demand declaration in c, throughout c.

A single-static-import declaration d in a compilation unit c of package p that imports a method named n with signature s shadows the declaration of any static method named n with signature s imported by a static-import-on-demand declaration in c, throughout c.

A single-static-import declaration d in a compilation unit c of package p that imports a type named n shadows the declarations of:

• any static type named n imported by a static-import-on-demand declaration in c.
• any top level type (§7.6) named n declared in another compilation unit (§7.3) of p.
• any type named n imported by a type-import-on-demand declaration (§7.5.2) in c. throughout c.

Static imports do not shadow non-static methods or inner types.

So the toString does not shadow the non-static method. Since the name toString can refer to a non-static method of A, it does cannot refer to the static method of Arrays and thus toString binds to the only method named toString that is available in scope, which is String toString(). That method cannot take any arguments so you get a compile error.

Section 15.12.1 explains method resolution and would have to have been completely rewritten to allow shadowing of unavailable method names within static methods but not inside member methods.

My guess is that the language designers wanted to keep method resolution rules simple, which means that the same name means the same thing whether it appears in a static method or not, and the only thing that changes is which are available.