27

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?

Lion
  • 18,729
  • 22
  • 80
  • 110
Stan Kurilin
  • 15,614
  • 21
  • 81
  • 132
  • It seems to be referring its super's Object's `toString()` – jmj Jan 23 '12 at 13:17
  • 2
    IMHO, the whole static import functionality is a bad concept, polluting namespaces and messing code readibility. Don't be lazy, it's not too hard to type the enclosing class/interface of a static function, we have IDEs for that. Try to avoid using static imports. – buc Jan 23 '12 at 13:18
  • @Jigar Joshi, It seams so. But I can't find anything about. And more, we can not call `Object.toString` from static context so I don't see any logic in this behavior. – Stan Kurilin Jan 23 '12 at 13:22
  • @buc Good point. But I want to understand it now. – Stan Kurilin Jan 23 '12 at 13:29
  • 8
    @buc Meh. Static imports are perfectly fine under many circumstances and can greatly increase readability. I can't imagine using a mocking library without them; that would be an atrocity. – Dave Newton Jan 23 '12 at 13:32
  • Since I didn't read the comment in the code example as a compilation error, I misinterpreted your question, so have removed my answer, since it's not helpful – chrisbunney Jan 23 '12 at 13:36
  • 1
    @Dave I agree, you just have to understand the pitfalls - because those can be bad. In this case it's not that bad because we just get a compile error, but in the worst case we could call the wrong function which certainly would make for fun debugging. – Voo Jan 23 '12 at 13:37

4 Answers4

25

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.

Community
  • 1
  • 1
Voo
  • 29,040
  • 11
  • 82
  • 156
  • 4
    The JLS link, should you need it - http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12.1 – alf Jan 23 '12 at 13:37
  • @alf Thanks, that makes for a much better answer now. I'd have added it myself if I'd known where to find the description for it in the JLS. – Voo Jan 23 '12 at 13:39
4

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.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • Except that as method `bar` is static, there's no instance to invoke `toString()` upon – chrisbunney Jan 23 '12 at 13:26
  • 2
    @StasKurilin [par. 6.3.1](http://java.sun.com/docs/books/jls/third_edition/html/names.html#34133) explains it more clearly. It says that the declaration of the instance method `Object.toString()` shadows *any other methods* in its scope. This includes the static import for `Arrays.toString(Object[])`. This means that, effectively, the static import has *no effect* - the compiler won't even consider it to resolve the method call. – millimoose Jan 23 '12 at 13:46
  • 3
    @inerdial, true, but if the name were not one that was defined on `java.lang.Object`, then it could have an effect. For example, `import static Foo.compareTo;` might be effective in one top-level class but not in another that `implements Comparable`. – Mike Samuel Jan 23 '12 at 13:50
1

If you try following similar looking code then you will not get any compiler error

import static java.util.Arrays.sort;
public class StaticImport {
    public void bar(int... args) {
        sort(args); // will call Array.sort
    }
}

The reason this compiles and yours doesn't is that the toString() (or any other method defined in class Object) are still scoped to Object class because of Object being the parent of your class. Hence when compiler finds matching signature of those methods from Object class then it gives compiler error. In my example since Object class doesn't have sort(int[]) method hence compiler rightly matches it with the static import.

anubhava
  • 761,203
  • 64
  • 569
  • 643
0

I do not think it is a bug or something different from normal import. For example, in case of normal import, if you have a private class with the same name as imported one the imported one will not be reflected.

yadab
  • 2,063
  • 1
  • 16
  • 24