在Java import语句中使用通配符并不坏。

在《Clean Code》中，Robert C. Martin建议使用它们来避免冗长的导入列表。

以下是建议:

J1: Avoid Long Import Lists by Using Wildcards 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. 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. 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. 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.

There is no runtime impact, as compiler automatically replaces the * with concrete class names. If you decompile the .class file, you would never see import ...*. C# always uses * (implicitly) as you can only using package name. You can never specify the class name at all. Java introduces the feature after c#. (Java is so tricky in many aspects but it's beyond this topic). In Intellij Idea when you do "organize imports", it automatically replaces multiple imports of the same package with *. This is a mandantory feature as you can not turn it off (though you can increase the threshold). The case listed by the accepted reply is not valid. Without * you still got the same issue. You need specify the pakcage name in your code no matter you use * or not.

它使您的名称空间变得混乱，要求您完全指定任何有歧义的类名。最常见的情况是:

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

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

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

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

如果你正在使用一个IDE(这是你应该做的)，并且有比你更多的代码所有者，使用通配符导入是不好的，因为它:

对团队其他成员隐瞒信息 提供给您的只是虚假的好处(使用IDE功能比使用通配符导入更好地解决的事情)

大多数“使用通配符”的支持者都专注于个人:我不想维护列表，我不想看到混乱等等。下面是几个常见的例子:

维护更加困难——当您想要在源代码中引入一个新类时，您必须手动添加import语句 重构更加困难——如果代码被移动了，那么导入语句就必须更新 减少混乱，整理文件内容——这里的目标是“消除干扰”。

These arguments were more convincing before IDEs did all of that automatically. If you're using a plain text editor instead of an IDE, then these arguments have some merit. But if you're using a plain text editor, you are already subjecting yourself to a number of other much more significant inefficiencies, and managing import statements is just one among many things that you should stop doing by hand. IDEs offer automatic management of imports, powerful refactoring tools, and folding (hiding) of any parts of the code you don't want to see.

对于“避免通配符”的支持者，有很多例子，但我只指出一个:

清晰度——特别是当有新人进入代码库时。他们将带着问题来到这里，并在探索代码的过程中继续发现新的问题。对于这个新的代码贡献者，通配符导入语句不能回答任何问题，在最坏的情况下可能会产生混乱、误解和新问题。相反，对于显式导入(并使用IDE)，最坏的情况是中性的:没有提供新的信息;最好的情况是，它不仅可以减少歧义，而且还可以提供答案。

在一天结束的时候，它帮助整个团队降低(尽管是以一种很小的方式)代码的复杂性，减少混乱，增加清晰度。

在双方提出的所有有效观点中，我还没有找到避免通配符的主要原因:我喜欢能够阅读代码并直接知道每个类是什么，或者如果它的定义不在语言或文件中，那么在哪里可以找到它。如果用*导入了多个包，我必须搜索它们中的每一个，以找到我不认识的类。可读性是至高无上的，我同意代码不应该需要IDE来读取。

我更喜欢特定的导入，因为它允许我查看文件中使用的所有外部引用，而无需查看整个文件。(是的，我知道不一定会有完全合格的推荐信。但我尽量避免使用。)