为什么使用带有Java导入语句的通配符是不好的?

It is much more convenient and cleaner to use a single statement like

使用单个语句就更方便、更简洁了。

import java.awt.*;

than to import a bunch of individual classes

而不是导入一堆单独的类

import java.awt.Panel;
import java.awt.Graphics;
import java.awt.Canvas;
...

What is wrong with using a wildcard in the import statement?

在导入语句中使用通配符有什么问题?

13 个解决方案

#1

The only problem with it is that it clutters your local namespace. For example, let's say that you're writing a Swing app, and so need java.awt.Event, and are also interfacing with the company's calendaring system, which has com.mycompany.calendar.Event. If you import both using the wildcard method, one of these three things happens:

它唯一的问题是它会混淆本地名称空间。例如，假设您正在编写一个Swing应用程序，因此需要java.awt。事件，并与公司的日历系统交互，该系统有com.mycompany.calendar.Event。如果您同时使用通配符方法进行导入，会发生以下三种情况之一:

1. You have an outright naming conflict between java.awt.Event and com.mycompany.calendar.Event, and so you can't even compile.
2. java.awt之间存在直接的命名冲突。事件和com.mycompany.calendar。事件，所以您甚至不能编译。
3. You actually manage only to import one (only one of your two imports does .*), but it's the wrong one, and you struggle to figure out why your code is claiming the type is wrong.
4. 实际上，您只管理导入一个(您的两个导入中只有一个是)，但它是错误的，并且您很难弄明白为什么您的代码声称类型是错误的。
5. When you compile your code there is no com.mycompany.calendar.Event, but when they later add one your previously valid code suddenly stops compiling.
6. 当你编译代码时，没有com.mycompany.calendar。事件，但是当他们以后添加一个之前有效的代码时，突然停止编译。

The advantage of explicitly listing all imports is that I can tell at a glance which class you meant to use, which simply makes reading the code that much easier. If you're just doing a quick one-off thing, there's nothing explicitly wrong, but future maintainers will thank you for your clarity otherwise.

显式列出所有导入的好处是，我可以一眼看出您想要使用哪个类，这只会使阅读代码更容易。如果您只是做了一件简单的事情，没有什么明显的错误，但是未来的维护人员会感谢您的清晰。

#2

Here's a vote for star imports. An import statement is intended to import a package, not a class. It is much cleaner to import entire packages; the issues identified here (e.g. java.sql.Date vs java.util.Date) are easily remedied by other means, not really addressed by specific imports and certainly do not justify insanely pedantic imports on all classes. There is nothing more disconcerting than opening a source file and having to page through 100 import statements.

这里是明星进口的投票。导入语句用于导入包，而不是类。导入整个包要干净得多;这里标识的问题(例如java.sql)。Date vs . java.util.Date)很容易通过其他方式进行补救，不是通过特定的导入进行真正的处理，当然也不值得在所有类上进行疯狂的迂腐导入。没有什么比打开一个源文件并必须通过100个导入语句来进行分页更令人不安的了。

Doing specific imports makes refactoring more difficult; if you remove/rename a class, you need to remove all of its specific imports. If you switch an implementation to a different class in the same package, you have to go fix the imports. While these extra steps can be automated, they are really productivity hits for no real gain.

执行特定的导入会使重构更加困难;如果您删除/重命名一个类，您需要删除它的所有特定导入。如果将实现切换到同一包中的另一个类，则必须修复导入。虽然这些额外的步骤可以被自动化，但它们实际上是没有实际收获的生产力。

If Eclipse didn't do class imports by default, everyone would still be doing star imports. I'm sorry, but there's really no rational justification for doing specific imports.

如果Eclipse在默认情况下不做类导入，那么每个人仍然会做星型导入。很抱歉，但是做特定的导入并没有合理的理由。

Here's how to deal with class conflicts:

以下是如何处理阶级冲突的方法:

import java.sql.*;
import java.util.*;
import java.sql.Date;

#3

please see my article Import on Demand is Evil

请见我的文章按需进口是邪恶的

In short, the biggest problem is that your code can break when a class is added to a package you import. For example:

简而言之，最大的问题是当类被添加到您导入的包中时，您的代码可能会崩溃。例如:

import java.awt.*;
import java.util.*;

// ...

List list;

In Java 1.1, this was fine; List was found in java.awt and there was no conflict.

在Java 1.1中，这很好;在java中找到了List。没有冲突。

Now suppose you check in your perfectly working code, and a year later someone else brings it out to edit it, and is using Java 1.2.

现在，假设您检入了运行良好的代码，一年后有人将它带出来进行编辑，并使用Java 1.2。

Java 1.2 added an interface named List to java.util. BOOM! Conflict. The perfectly working code no longer works.

Java 1.2向Java .util添加了一个名为List的接口。繁荣!冲突。完美工作的代码不再工作。

This is an EVIL language feature. There is NO reason that code should stop compiling just because a type is added to a package...

这是一种邪恶的语言特征。代码不应该停止编译，因为一个类型被添加到一个包中……

In addition, it makes it difficult for a reader to determine which "Foo" you're using.

此外，它使读者很难确定您使用的是哪个“Foo”。

#4

It's not bad to use a wild card with a Java import statement.

使用带有Java import语句的通配符并不坏。

In Clean Code, Robert C. Martin actually recommends using them to avoid long import lists.

在Clean Code中，Robert C. Martin实际上建议使用它们来避免长时间的导入列表。

Here is the recommendation:

这是推荐:

J1: Avoid Long Import Lists by Using Wildcards

J1:使用通配符避免长导入列表

If you use two or more classes from a package, then import the whole package with

如果您使用一个包中的两个或多个类，那么使用它来导入整个包

import package.*;

导入包。*;

Long lists of imports are daunting to the reader. We don’t want to clutter up the tops of our modules with 80 lines of imports. Rather we want the imports to be a concise statement about which packages we collaborate with.

对读者来说，一长串的进口商品清单让人望而生畏。我们不希望在模块的顶部塞满80行导入。相反，我们希望导入是一个关于与哪些包协作的简明声明。

Specific imports are hard dependencies, whereas wildcard imports are not. If you specifically import a class, then that class must exist. But if you import a package with a wildcard, no particular classes need to exist. The import statement simply adds the package to the search path when hunting for names. So no true dependency is created by such imports, and they therefore serve to keep our modules less coupled.

特定的导入是硬依赖项，而通配符导入不是。如果您特别导入一个类，那么这个类必须存在。但是，如果您导入一个带有通配符的包，则不需要存在任何特定的类。import语句只是在搜索名称时将包添加到搜索路径中。因此，这些导入不会创建真正的依赖关系，因此它们可以减少模块的耦合。

There are times when the long list of specific imports can be useful. For example, if you are dealing with legacy code and you want to find out what classes you need to build mocks and stubs for, you can walk down the list of specific imports to find out the true qualified names of all those classes and then put the appropriate stubs in place. However, this use for specific imports is very rare. Furthermore, most modern IDEs will allow you to convert the wildcarded imports to a list of specific imports with a single command. So even in the legacy case it’s better to import wildcards.

有时，特定导入的长列表是有用的。例如,如果您在处理遗留代码和你想找出类需要构建模拟和存根,你可以沿着特定的列表找出真正的合格的进口所有这些类的名称,然后把相应的存根。然而，这种对特定导入的使用非常罕见。此外，大多数现代ide都允许您使用单个命令将通配符导入转换为特定导入的列表。因此，即使在遗留的情况下，也最好导入通配符。

Wildcard imports can sometimes cause name conflicts and ambiguities. Two classes with the same name, but in different packages, will need to be specifically imported, or at least specifically qualified when used. This can be a nuisance but is rare enough that using wildcard imports is still generally better than specific imports.

通配符导入有时会导致名称冲突和歧义。两个具有相同名称但在不同包中的类将需要特别导入，或者至少在使用时需要特别限定。这可能是一种麻烦，但很少使用通配符导入通常比特定的导入要好。

#5

It clutters your namespace, requiring you to fully specify any classnames that are ambiguous. The most common occurence of this is with:

它使名称空间混乱，要求您完全指定任何不明确的类名。最常见的情况是:

import java.util.*;
import java.awt.*;

...
List blah; // Ambiguous, needs to be qualified.

It also helps make your dependencies concrete, as all of your dependencies are listed at the top of the file.

它还有助于使依赖项具体化，因为所有依赖项都列在文件的顶部。

#6

Performance: No impact on performance as byte code is same. though it will lead to some compile overheads.

性能:对性能没有影响，因为字节代码是相同的。尽管这会导致一些编译开销。

Compilation: on my personal machine, Compiling a blank class without importing anything takes 100 ms but same class when import java.* takes 170 ms.

编译:在我的个人计算机上，在不导入任何内容的情况下编译一个空白类需要100 ms，但是在导入java时需要使用相同的类。*需要170 ms。

#7

1. It helps to identify classname conflicts: two classes in different packages that have the same name. This can be masked with the * import.
2. 它有助于识别类名冲突:不同包中具有相同名称的两个类。可以用*导入来掩盖这一点。
3. It makes dependencies explicit, so that anyone who has to read your code later knows what you meant to import and what you didn't mean to import.
4. 它使依赖项变得显式，以便以后必须阅读您的代码的任何人都知道您要导入什么，以及您不打算导入什么。
5. It can make some compilation faster because the compiler doesn't have to search the whole package to identify depdencies, though this is usually not a huge deal with modern compilers.
6. 它可以使编译速度更快，因为编译器不需要搜索整个包来确定深度，尽管这对现代编译器来说通常不是什么大问题。
7. The inconvenient aspects of explicit imports are minimized with modern IDEs. Most IDEs allow you to collapse the import section so it's not in the way, automatically populate imports when needed, and automatically identify unused imports to help clean them up.
8. 显式导入的不便之处可以用现代ide最小化。大多数ide都允许您折叠导入部分，这样就不会妨碍导入，在需要时自动填充导入，并自动识别未使用的导入以帮助清理它们。

Most places I've worked that use any significant amount of Java make explicit imports part of the coding standard. I sometimes still use * for quick prototyping and then expand the import lists (some IDEs will do this for you as well) when productizing the code.

我工作过的大多数地方都使用大量的Java，使显式导入成为编码标准的一部分。我有时仍然使用*进行快速原型，然后在生成代码时展开导入列表(有些ide也会这样做)。

#8

I prefer specific imports, because it allows me to see all the external references used in the file without looking at the whole file. (Yes, I know it won't necessarily show fully qualified references. But I avoid them whenever possible.)

我更喜欢特定的导入，因为它允许我查看文件中使用的所有外部引用，而不需要查看整个文件。(是的，我知道它不一定能提供完全合格的参考资料。但只要有可能，我就会避开它们。

#9

In a previous project I found that changing from *-imports to specific imports reduced compilation time by half (from about 10 minutes to about 5 minutes). The *-import makes the compiler search each of the packages listed for a class matching the one you used. While this time can be small, it adds up for large projects.

在之前的一个项目中，我发现从*-导入到特定的导入会使编译时间减少一半(从大约10分钟到大约5分钟)。导入使编译器可以搜索与您使用的类匹配的每个包。虽然这一次的规模可能很小，但对于大型项目来说，这是一个不小的数目。

A side affect of the *-import was that developers would copy and paste common import lines rather than think about what they needed.

导入的一个副作用是开发人员会复制和粘贴通用的导入行，而不是考虑他们需要什么。

#10

In DDD book

在DDD的书

In whatever development technology the implementation will be based on, look for ways of minimizing the work of refactoring MODULES . In Java, there is no escape from importing into individual classes, but you can at least import entire packages at a time, reflecting the intention that packages are highly cohesive units while simultaneously reducing the effort of changing package names.

在任何开发技术中，实现都将基于，寻找最小化重构模块工作的方法。在Java中，不能避免将包导入到单独的类中，但是您至少可以一次导入整个包，这反映了包是高度内聚的单元，同时减少了更改包名的工作量。

And if it clutters local namespace its not your fault - blame the size of the package.

如果它把本地的名称空间搞混了，那不是你的错——怪这个包的大小。

#11

The most important one is that importing java.awt.* can make your program incompatible with a future Java version:

最重要的是导入java.awt。*可以使您的程序与未来的Java版本不兼容:

Suppose that you have a class named "ABC", you're using JDK 8 and you import java.util.*. Now, suppose that Java 9 comes out, and it has a new class in package java.util that by coincidence also happens to be called "ABC". Your program now will not compile on Java 9, because the compiler doesn't know if with the name "ABC" you mean your own class or the new class in java.awt.

假设您有一个名为“ABC”的类，您正在使用JDK 8并导入java.util.*。现在，假设Java 9出来了，它在包Java中有一个新类。碰巧的是，这个词也被称为“ABC”。您的程序现在将不会在Java 9上编译，因为编译器不知道如果名称为“ABC”，您是指您自己的类还是Java .awt中的新类。

You won't have that problem when you import only those classes explicitly from java.awt that you actually use.

当您只从java显式地导入这些类时，您就不会遇到这个问题。你实际使用的awt。

Resources:

资源:

Java Imports

Java进口

#12

Among all the valid points made on both sides I haven't found my main reason to avoid the wildcard: I like to be able to read the code and know directly what every class is, or if it's definition isn't in the language or the file, where to find it. If more than one package is imported with * I have to go search every one of them to find a class I don't recognize. Readability is supreme, and I agree code should not require an IDE for reading it.

在两边的所有有效点中，我没有找到避免通配符的主要原因:我喜欢能够读懂代码并直接知道每个类是什么，或者如果它的定义不在语言或文件中，那么我想在哪里找到它。如果有多个包被*导入，我必须搜索它们中的每一个，找到一个我不认识的类。可读性是最重要的，我同意代码不应该需要IDE来读取它。

#13

There is no runtime impact, as compiler automatically replaces * with concrete classes' name. If you decompile the .class file, you will never see "import xxx.*".

没有运行时影响，因为编译器会自动用具体类的名称替换*。如果对.class文件进行反编译，就不会看到“import xxx.*”。

In c# you can only "using" package name without class name.

在c#中，您只能使用没有类名的包名。

In Intellij Idea when you do "organize imports", it automatically replaces multiple imports of the same package with *.

在Intellij Idea中，当你进行“组织导入”时，它会自动用*替换同一个包的多个导入。

The advantages and disadvantages of using * vary depending on your usages. In most cases, I do not encounter the situations listed by the accepted reply. If you presumed it's "bad", you cannot explain why java introduces it and Intellij replaces it.

使用*的优点和缺点取决于您的用法。在大多数情况下，我没有遇到被接受的答复所列出的情况。如果您假定它是“坏的”，您就无法解释为什么java引入它并Intellij替换它。