Import package. * Vs import package.SpecificType

Question

Is it possible to assume that any difference in overhead costs for import records loads all types within a single package ( import java.* ); than a specific type (i.e. import java.lang.ClassLoader )? Would the second option be more appropriate than the other?

Answer 1

Import does not require performance or overhead. * vs import of certain types. However, I find it best practice never to use imports. * My main reason is that I just want to keep things straightforward, clean and with as little ambiguity as possible, and I think that you lose with import.

Answer 2

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

For example:

 java.lang.reflect.Array java.sql.Array 

So, if you import java.lang.reflect.* And java.sql.* , You will have a collision with the type of the array, and you must fully define them in your code.

Importing specific classes instead will save you from this problem.

Answer 3

This is actually a very bad problem.

Suppose you write

 import a.*; import b.*; ... Foo f; 

and the class Foo exists in package a.

Now you are checking your perfectly compiled code, and after six months someone will add the Foo class to package b. (Perhaps this is a third-party library adding classes in the latest version).

Poof! Now your code refuses to compile.

Never use import on demand. This evil!

See http://javadude.com/articles/importondemandisevil.html for more details.

Performance RE:

 import a.*; 

against

 import aX; 

Does not affect runtime. The compiler corrects the resolved class names in the generated .class files.

Answer 4

Minority view: in my code. I try to use tons of classes from several packages along with several odd classes here and there. I like to keep the import list small so that I can understand what is happening at a glance. To do this, I set the threshold to 4 classes. Above this, Eclipse will use * for my code. I find that this allows me to import my package, and I tend to refer to them as the first thing I do when I look at the class to answer the question: who is he talking to?

As for name conflicts: What are the chances that you are importing four or more classes from two packages that have competing class names? IF this is more than 10% of the time, you can consider the number of packages your class relies on (for example, reorganize it into smaller classes).

Answer 5

A good reason to never use xxx imports. * - have a clear vision of dependencies.

You can find out more quickly that you are using a specific class of another package because it is listed at the beginning of the source file.

Answer 6

After searching for more information, I came across this site where it is very well explained. Import problem and Does using * in the import statement use performance? .

Is there a performance problem between these two styles? It is possible, but since import ads do not actually import anything into your program, any difference is very small. Remember that there is an implicit import of 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 far-fetched example, one of which uses thousands of class names to look for, showed a slight change in compilation speed. Thus, compilation performance should probably not be seen as a factor when choosing one format over another.

There is one final angle of interest in import declarations. Suppose you use an inner class:

 package P; public class A { public static class B {} } 

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

 import P.*; 

or: import PA; But if you want to access B without qualifications, you need to say:

 import PA*; 

or: import PAB; The first one provides available types in class A found in package P. The second allows you to get only type B found in class A in package P.

Answer 7

I use everything that was the default IDE. I believe this should not be particularly worried, since it does not affect performance, and dependency checking can be handled using various tools.

Answer 8

Import does not matter at the bytecode level, so there should be no difference in runtime.

I believe that the best is: a) Be clear by specifying all imports b) Let your IDE handle this. Any of the core IDEs can automatically update, sort, and complete the import.

I found a) come in handy a couple of times when manually repackaging out of the context of refactoring in the IDE. For example, when marketing changes the name of your product and decides that all of your packages should change their name.

Answer 9

If you import more than 20 classes from one package, you are better off using xxx import. *. Clean Code supports the import of the entire package.

Answer 10

This is a good coding practice, since anyone who reads your code will immediately recognize which classes are used by a particular class, simply by looking at the import block at the top of the file, while they will need to dig to find out which wildcards are used.