Java 静态导入

发布于 2024-12-28 14:18:43 字数 478 浏览 0 评论 0原文

通过实验,我发现 Java 非静态方法会覆盖范围内所有相同命名的方法,即使在静态上下文中也是如此。即使不允许参数重载。就像

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[])
    }
}

我在规范中找不到任何关于此的信息。这是一个错误吗?如果不是,是否有任何理由实施这样的语言?

UPD:Java 6 不编译此示例。问题是 - 为什么?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

以往的大感动 2025-01-04 14:18:43

解释很简单,但它并没有改变行为非常不直观的事实:

在解析要调用的方法时,编译器要做的第一件事就是找到具有正确名称的方法的最小封闭范围。然后才会出现其他事情,例如游戏中的重载解析和合作。

现在这里发生的事情是,包含 toString() 方法的最小封闭范围是从 Object 继承它的类 A。因此我们就停在那里,不再继续搜索。遗憾的是,接下来编译器尝试在给定范围内找到最适合的方法,并注意到它无法调用其中任何一个并给出错误。

这意味着永远不要静态导入名称与 Object 中的方法相同的方法,因为自然在范围内的方法优先于静态导入(JLS 描述了方法遮蔽)详细,但对于这个问题,我认为记住这一点要简单得多)。

编辑:@alf 请提交 JLS 的正确部分,为那些想要了解整个情况的人描述了方法调用。这是相当复杂的,但问题也不简单,所以这是可以预料的。

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.

盛夏已如深秋| 2025-01-04 14:18:43

这不是覆盖。如果它确实有效,this.toString() 仍然会访问 A 的方法,而不是 Arrays.toString ,就像重写时的情况一样已经发生了。

语言规范解释说静态导入仅影响static 方法和类型的解析:

包 p 的编译单元 c 中的单静态导入声明 d 导入名为 n 的字段,在整个 c 中隐藏由 c 中的静态导入按需声明导入的任何名为 n 的静态字段的声明.

包 p 的编译单元 c 中的单静态导入声明 d 导入带有签名 s 的名为 n 的方法,该声明会遮蔽由 a 导入的带有签名 s 的任何静态方法的声明c 中的静态导入按需声明,贯穿整个 c。

包 p 的编译单元 c 中的单静态导入声明 d 导入名为 n 的类型,遮蔽了以下声明:

  • 由 c 中的静态导入按需声明导入的任何名为 n 的静态类型
  • 在 p 的另一个编译单元 (§7.3) 中声明的任何名为 n 的顶级类型 (§7.6)。
  • 由 c 中的类型导入按需声明(第 7.5.2 节)导入的任何名为 n 的类型。
    整个c.

静态导入不会隐藏非静态方法或内部类型。

因此 toString 不会隐藏非静态方法。由于名称 toString 可以引用 A 的非静态方法,因此它不能引用 Arrays< 的 static 方法/code> ,因此 toString 绑定到范围内可用的唯一名为 toString 的方法,即 String toString()。该方法不能接受任何参数,因此您会收到编译错误。

第 15.12.1 节 解释了方法解析并会必须完全重写,以允许隐藏 static 方法中不可用的方法名称,但不能隐藏 member 方法中的方法名称。

我的猜测是,语言设计者希望保持方法解析规则简单,这意味着相同的名称无论是否出现在静态方法中都意味着相同的事情,唯一改变的是哪个可用。

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.

泪眸﹌ 2025-01-04 14:18:43

如果您尝试遵循类似的代码,那么您将不会收到任何编译器错误。

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

此代码可以编译而您的代码不能编译的原因是toString() (或 Object 类中定义的任何其他方法)的作用域仍然是 Object 类,因为 Object 是您的类的父类。因此,当编译器从 Object 类中找到这些方法的匹配签名时,它会给出编译器错误。在我的示例中,由于 Object 类没有 sort(int[]) 方法,因此编译器会将其与静态导入正确匹配。

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.

╄→承喏 2025-01-04 14:18:43

我不认为这是一个错误或与正常导入不同的东西。例如,在正常导入的情况下,如果您有一个与导入的私有类同名的私有类,则导入的私有类将不会被反映。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文