blocks|key|3114223|text|与导入特定类型相比，导入.*不会产生性能或开销成本。然而，我认为永远不要使用导入.*是一种最佳实践。我这样做的主要原因是我只想让事情变得简单、干净，并且尽可能少含糊不清，而我认为使用.*导入就会失去这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3114224|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There is not a performance or overhead cost to doing import .* vs importing specific types. However, I consider it to be a best practice to never use import .* My primary reason for this is I just like to keep things straightward, clean and with as little ambiguity as possible, and I think with a .* import you lose that.

blocks|key|5369708|text|看一看java+API，您会在不同的包中看到许多同名的类和接口。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5369709|例如：|5369710|java.lang.reflect.Array
java.sql.Array|code-block|syntax|javascript|5369711|因此，如果您导入java.lang.reflect.*和java.sql.*，您将在数组类型上发生冲突，并且必须在您的代码中完全限定它们。|offset|length|style|CODE|5369712|相反，导入特定的类可以省去这方面的麻烦。|5369713|entityMap^0|0|0|0|8|J|S|A|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@$K|W|L|X|M|N]|$K|Y|L|Z|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Take a look at the java API, and you'll see many classes and interfaces with the same name in different packages.

For example:

<pre><code>java.lang.reflect.Array
java.sql.Array
</code></pre>

So, if you import <code>java.lang.reflect.*</code> and <code>java.sql.*</code> you'll have a collision on the Array type, and have to fully qualify them in your code.

Importing specific classes instead will save you this hassle.

blocks|key|5370142|text|这实际上是一个非常糟糕的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5370143|假设你写道|5370144|import+a.*;
import+b.*;
...
Foo+f;|code-block|syntax|javascript|5370145|并且类Foo存在于包a中。|5370146|现在，您签入了完美编译的代码，六个月后，有人将类Foo添加到包b中(可能是第三方库在最新版本中添加了类)。|5370147|哇塞！现在，您的代码拒绝编译。|5370148|从不使用按需导入。这是邪恶的！|offset|length|style|BOLD|5370149|有关更多详细信息，请参阅http://javadude.com/articles/importondemandisevil.html。|5370150|RE性能：|5370151|import+a.*;|5370152|vs|5370153|import+a.X;|5370154|在运行时没有区别。编译器将解析的类名硬连接到生成的.class文件中。|5370155|entityMap|0|LINK|mutability|MUTABLE|url|http://javadude.com/articles/importondemandisevil.html^0|0|0|0|0|0|0|0|2|0|C|1I|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1F|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1G|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1H|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1J|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1K|8|@$Q|1L|R|1M|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1N|8|@]|9|@$Q|1O|R|1P|1|1Q]]|A|$]]|$1|W|3|X|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1S|8|@]|9|@]|A|$G|H]]|$1|10|3|11|5|6|7|1T|8|@]|9|@]|A|$]]|$1|12|3|13|5|F|7|1U|8|@]|9|@]|A|$G|H]]|$1|14|3|15|5|6|7|1V|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]]]

This is actually a very bad problem.

Suppose you write

<pre><code>import a.*;
import b.*;
...
Foo f;
</code></pre>

and class Foo exists in package a.

Now you check in your perfectly compiling code, and six months later, someone adds class Foo to package b. (Perhaps it's a third party lib that added classes in the latest version).

Poof! Now your code refuses to compile.

Never use import-on-demand. It's evil!

See <a href="http://javadude.com/articles/importondemandisevil.html" rel="noreferrer">http://javadude.com/articles/importondemandisevil.html</a> for more details.

RE performance:

<pre><code>import a.*;
</code></pre>

vs

<pre><code>import a.X;
</code></pre>

Makes no difference at runtime. The compiler hardwires the resolved class names into the generated .class files.

blocks|key|5370190|text|少数观点：在我的代码中，我倾向于使用几个包中的大量类，以及一些奇怪的类。我喜欢保持我的进口清单很小，这样我就可以一眼就知道发生了什么。为此，我将阈值设置为4个类。除此之外，Eclipse将在我的代码中使用*。我发现这使我的包导入保持了可读性，当我查看一个类时，我倾向于将它们称为我做的的第一件事，以回答这个问题:它与谁对话？|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|5370191|关于名称冲突的：从具有竞争类名称的两个包中导入四个或更多类的可能性是多少？如果超过10%25的时间，你可能想要考虑你的类所依赖的包的数量(例如，将其重构为更小的类)。|5370192|entityMap^0|0|5|0|7|1|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Minority view: in my code I tend to use tons of classes from a few packages along with a few odd classes here and there. I like to keep my imports list small so I can tell what is going on at a glance. To do this, I set the threshold at 4 classes. Above that, Eclipse will use * for my code. I find this keeps my package imports readable, and I tend to refer to them as the first thing I do when I look at a class, to answer the question: Who does it talk to?

Regarding Name Collision: What are the chances that you import four or more classes from two packages that have competing class names? IF it's more than 10% of the time, you might want to consider the number of packages your class relies on (e.g., refactor it into smaller classes).

blocks|key|3114310|text|永远不要使用导入xxx.*的一个很好的理由是对dependencies有一个清晰的认识。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3114311|您可以更快地知道您正在使用另一个包的特定类，因为它就列在源文件的开头。|3114312|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/62276^0|N|C|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

A good reason to never use import xxx.* is to have a clear vision of <a href="https://stackoverflow.com/questions/62276">dependencies</a>.

You can know quicker that you are using a specific class of another package because it is listed right at the beginning of the source file.

blocks|key|809857|text|在寻找了更多的信息后，我偶然发现了这个网站，在那里它有很好的解释。Import+issue和Does+using+*+in+an+import+statement+affect+performance?。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|809858|这两种风格之间是否存在效率问题？有可能，但由于导入声明实际上不会将任何内容导入到您的程序中，因此任何差异都非常小。请记住，在编译单元的顶部有一个隐式的import+java.lang.*，JDK1.2.2中的java.lang包含75个类和接口。使用一个人为设计的示例进行的实验显示，编译速度的变化可以忽略不计。因此，在选择一种格式而不是另一种格式时，编译性能可能不是一个因素。|809859|关于进口声明还有最后一个关注点。假设你使用一个内部类：|809860|package+P;

public+class+A+{
++++public+static+class+B+{}
}|code-block|syntax|javascript|809861|如果你想从另一个编译单元访问A，你可以说：|809862|import+P.*;|809863|或者:导入P.A；但如果您想无资质访问B，则需要说：|809864|import+P.A.*;|809865|或者:导入P.A.B；第一个使在包P中找到的类A中的类型可用；第二个使在包P中的类A中找到的类型B可用。|809866|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/developer/TechTips/2000/tt0110.html#tip2|1|http://www.javaperformancetuning.com/news/qotm031.shtml^0|X|C|0|1A|1J|1|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]|$A|1A|B|1B|1|1C]]|C|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1E|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1F|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1G|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|1H|8|@]|9|@]|C|$K|L]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@]|C|$]]|$1|S|3|T|5|J|7|1J|8|@]|9|@]|C|$K|L]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]|14|$5|Z|10|11|C|$12|15]]]]

After looking for further information, I came across this website where it is very well explained. <a href="http://java.sun.com/developer/TechTips/2000/tt0110.html#tip2" rel="noreferrer" title="Import issue">Import issue</a> and <a href="http://www.javaperformancetuning.com/news/qotm031.shtml" rel="noreferrer" title="Does using * in an import statement affect performance?">Does using * in an import statement affect performance?</a>.

Is there any efficiency issue between these two styles? Possibly, but since import declarations don't actually import anything into your program, any difference is very small. Remember that there's an implicit import java.lang.* at the top of your compilation units, and java.lang in JDK 1.2.2 contains 75 classes and interfaces. An experiment using a contrived example, one with thousands of class name uses that must be looked up, showed a negligible change in compilation speed. So compilation performance should probably not be considered a factor when choosing one format over another.

There's one final angle of interest on import declarations. Suppose you use an inner class:

<pre><code>package P;

public class A {
 public static class B {}
}
</code></pre>

If you want to access A from another compilation unit, you say:

<pre><code>import P.*;
</code></pre>

or:
 import P.A;
But if you'd like to access B without qualification, you need to say:

<pre><code>import P.A.*;
</code></pre>

or:
 import P.A.B;
The first of these makes available types within the class A found in package P. The second makes available just the type B found in class A in package P.

blocks|key|5370016|text|我倾向于使用IDE的默认设置。我发现这并不是真正值得担心的事情，因为它不会对性能产生影响，而且检查依赖关系可以使用各种工具来处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5370017|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I tend to use whatever the IDE default is. I find that it is not something really worth worrying about since it has no performance impact, and checking dependencies can be handled with a variety of tools.

blocks|key|810040|text|如果要从同一个包中导入20个以上的类，最好使用import+xxx.*。"Clean+Code“也支持导入整个包。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|810041|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you are importing more than 20 classes from the same package, you are better off using import xxx.*. "Clean Code" is in favor importing the whole package as well.

blocks|key|5370080|text|导入在字节码级别并不重要，因此应该没有运行时差异。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5370081|我发现最好的方法是:+a)明确列出所有导入；b)让IDE管理它。任何主要的IDE都可以自动更新、排序和完成导入。|5370082|我发现a)在IDE内重构的上下文之外进行手动重新打包时，有几次会派上用场。例如，当市场营销更改了产品的名称，并决定所有的包都应该更改名称时。|5370083|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The imports don't matter at bytecode level, so there should be no runtime difference. 

I find it's best to:
a) Be explicit by listing all imports
b) Let your IDE manage it. Any of the major IDEs can automatically update, sort, and complete your imports.

I have found a) to come in handy a couple times when doing manual repackaging outside the context of an in-IDE refactoring. Like for instance, when marketing changes the name of your product and decides all of your packages should change name.

blocks|key|5370246|text|这是一种更好的编码实践，因为任何阅读您的代码的人只需查看文件顶部的import块，就可以立即知道特定类使用了哪些类，而您必须深入了解您是否使用了通配符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5370247|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's more of a good coding practice as anyone reading your code will immediately know what classes are used by a particular class by just looking at the import block at the top of the file whereas one would have to dig to find out if you used wildcards.

Would it suppose any difference regarding overhead to write an import loading all the types within one package (<code>import java.*</code>); than just a specific type (i.e. <code>import java.lang.ClassLoader</code>)? Would the second one be a more advisable way to use than the other one?

Import package.* vs import package.SpecificType

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

与特定类型(即import java.lang.ClassLoader)相比，编写一个导入加载一个包(import java.*)中的所有类型的开销是否会有所不同？第二种方式会比另一种更可取吗？

问导入package。* vs导入package.SpecificType
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问导入package。* vs导入package.SpecificTypeEN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问导入package。* vs导入package.SpecificType
EN