Eclipse / Java - harmful for java import. (Namespace). *?

Question

Why does Eclipse use a fine-grained approach when importing types? In C #, I got used to things like "using System.Windows.Controls" and run with it, but Eclipse prefers to import each widget that I reference individually (using Ctrl + Shift + O). Is there any harm to importing an entire namespace if I know that I need several types in it?

Answer 1

The only harm that can cause import of wildcard packages is the increased likelihood of namespace conflicts if multiple packages have multiple classes with the same name.

Say, for example, I want to program the use of the ArrayList Framework Java Collections Framework class in an AWT application that uses the List GUI component to display information. For example, suppose we have the following:

 // 'ArrayList' from java.util ArrayList<String> strings = new ArrayList<String>(); // ... // 'List' from java.awt List listComponent = new List() 

Now, to use the above, there must be an import for these two classes, minimally:

 import java.awt.List; import java.util.ArrayList; 

Now, if we used a wildcard in the import package, we would have the following.

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

However, now we will have a problem!

There is a class java.awt.List and java.util.List , so the appeal to the List class will be ambiguous. We would have to turn to List with the full class name if we want to eliminate the ambiguity:

 import java.awt.*; import java.util.*; ArrayList<String> strings = new ArrayList<String>(); // ... // 'List' from java.awt -- need to use a fully-qualified class name. java.awt.List listComponent = new java.awt.List() 

Therefore, there are times when using the import wildcard package can lead to problems.

Answer 2

Eclipse has an excellent option called “Organize Import” in the “Window → Preferences” dialog box, which allows you to tell when N classes are used from the package, import the wildcards. I use it with N = 2 or 3 usually.

Answer 3

Someone can read your code without an IDE - in this case, import without wildcards will help him figure out which classes are used in your code.

Answer 4

The import directive is a compiler directive, it tells the compiler where to look for a class, and allows you to not always use fully qualified class names, for example. java.util.HashMap . But the import directives themselves do not fall into the compiled bytecode files, the compiler compiles the full name into the .class file.

When used without a wildcard, the directive explicitly tells the compiler to search for one specific file in the classpath. Using a template, the directive tells the compiler to search for a named package and to search in that package for possible matches every time any name should be matched. The latest version will probably take (bit) more for the compiler than the first.

In other words, the import directive can in no way affect the execution of the execution code. However, the import directive affects compilation time. In addition, I believe that using import with wildcards makes the code less readable.

Actually, the cost of import statements a matter of a month at javaperformancetuning.com summarizes this perfectly in its conclusion:

• There is no runtime overhead from using an import statement
• The compilation process may take a little longer with the import.
• The compilation process may take even longer using wildcard imports.
• To improve readability, wildcard import statements are bad practice for nothing but dropped classes.
• Compilation overhead for statements without wildcard imports: but they give readability advantages, so using them is best practice

Answer 5

I do not believe that importing wildcards has any performance implications (and if so, I think this will only happen at compile time). But since this SO address indicates , maybe you can have class names overlapping if you use them.

I just use Ctrl + Space to force import when I use a class not yet imported, and the import happens automatically. Then I press Ctrl + Shift + O after I reorganize the class to remove any imports that are no longer in use.

Answer 6

Until JDK 1.2 compiles this code:

 import java.awt.*; import java.util.*; public class Foo { // List is java.awt.List private List list; } 

in JDK 1.2, java.util.List is added, and the code no longer compiles because the compiler did not know which list was needed (awt or util). You can fix this by adding "import java.awt.List"; at the end of the import, but the fact is that you need to do something to fix it.

I personally use single imports instead of on-demand imports for two reasons:

• clear where each class comes from
• If you have a huge amount of import class, it is probably too much and should be separated. This is the "smell of code."

Answer 7

From the purist point of view, each import creates dependence and potential conflict. Import is seen as a necessary evil, so they are minimized. Importing another package with * is like writing a blank check. Importing two of these packages is about giving someone access to transfer money between your accounts.

From a practical point of view, this often makes sense, because different projects and libraries use surprisingly similar names for different concepts. Or, imagine you import everything from package A and then everything from package B and use some class C from package B. If someone later adds a class named C to package A, your code may break!

Having said that, I admit that I am lazy. I often pre-import everything into a package, and then let Eclipse organize it for me based on what I actually use.

Answer 8

There is no harm in importing all classes in the package / namespace, but I think it's better to include each individual class. This simplifies the work of developers who come after you exactly where every class comes from.

This is not a problem if you are using a compatible IDE such as IntelliJ. I would suggest that Eclipse and NetBeans can manage imports. He will add the code to you and hide them from view so that they do not clutter the window. What could be easier?

Answer 9

Doesn't damage the code. As a general principle, why import something if you are not going to use it?

Answer 10

If you write some java code like

 LinkedList<foo> llist = new LinkedList<foo>() 

and you did not import LinkedList into your project, Eclipse will ask if you want to import it. Since you are using LinkedList and nothing else, it will import LinkedList. If you are doing something in another project, for example, ArrayList<foo> alist = new ArrayList<foo>()

Then Eclipse will also say that you need to import an ArrayList, but nothing else. Eclipse uses only what you need based on any library calls. If you need several types or elements from the same library, there is no harm in using

import java.namespace.*

to go ahead and introduce other items that you need. Eclipse doesn't care while you import packages and libraries containing the elements you link to, such as Scanners, LinkedLists, etc.

In terms of readability, this is a different issue. If you want people to clearly know what exactly you are importing, then the call to each widget or package may be in order. This can become quite tedious if you use many different functions from one package in the standard library and can make your file headers quite long, therefore. * Wildcard. There is no harm in importing with wildcards; it really comes down to your coding standards and how transparent you want your class headers to be.

Answer 11

Importing each class explicitly gives a tight binding between a short name (for example, a proxy) and a long name (for example, java.lang.reflect.Proxy), rather than a loose binding saying that in java.lang.reflect.* java.io.* or java.net.* or elsewhere in the wildcard imports you import.

This can be a problem if for some reason another class called Proxy appears somewhere in java.io.* or java.net.* Or your own code, because the compiler then does not know which Proxy class you want, how if it were, if you had explicitly imported java.lang.reflect.Proxy.

The above example is not confirmed. The java.net.Proxy class was introduced in Java 5 and would break your code if it were written as outlined above. See Sun's official explanation on how to get around wildcard problems at http://java.sun.com/j2se/1.5.0/compatibility.html

(Importing wildcards is just a convenient mechanism for those who do not use the IDE to support import operators. If you use the IDE, then let this help you :)