Too many imports spamming my code

Question

In my project I have a shapes package which has shapes I designed for my graphics program e.g Rectangle, Circle. I also have one or two more packages that have the

Answer 1

I use explicit imports, and have done so for many years. In all my projects in the last decade this has been agreed with team members, and all are happy to agree to to use explicit imports, and avoid wildcards. It has not been controversial.

In favour of explicit imports:

• precise definition of what classes are used
• less fragile as other parts of the codebase changes
• easier to code review
• no guessing about which class is in which package

In favour of wildcards:

• less code
• easier to add and maintain the imports when using a text editor

Early in my career, I did use wildcard imports, because back then IDEs were not so sophisticated, or some of us just used text editors. Managing explicit imports manually is quite a bit of effort, so wildcard imports really help.

However at least once I was bitten by the use of wildcard imports, and this lead be to my current policy of explicit only.

Imagine you have a class that has 10 wildcard imports, and it compiles successfully. Then you upgrade 5 jar files to newer versions (you have to upgrade them all, because they are related). Then the code no longer compiles, there is a class not found error. Now which package was that class in? What is the full name of the class? I don't know because I'm only using the short name, now I have to diff the old and new versions of the jars, to see what has changed.

If I had used explicit imports, it would be clear which class had been dropped, and what it's package was, and this which jar (by looking of other classed in that package) is responsible.

There are also problems reading code history, or looking at historic merges. When you have wildcard imports there is uncertainty for the reader about which class is which, and thus what the semantics of the code changes are. With explicit imports you have a precise description of the code, and it acts as a better historical record.

So overall the benefit of the small amount of extra effort to maintain the import, and extra lines of code are easily outweighed by extra precision and determinism given by explicit imports.

The only case when I still use wildcards, is when there are more that 50 imports from the same package. This is rare, and usually just for constants.

Answer 2

Another alternative is to type the fully qualified class name as you need it. In my example, there are 2 Element object, one created by me org.opensearch.Element and the other org.w3c.dom.Element.

To resolve name conflict, as well as to minimize import "clutters", I've done this (in my org.opensearch.Element class):

public org.w3c.dom.Element toElement(org.w3c.dom.Document doc) { /* .... */ }

As you can see, the return Element type is fully-typed (i.e. I've specified the fully-qualifed class name of Element).

Problem solved! :-)

Answer 3

• It's a good practice to import class by class instead of importing whole packages

• Any good IDE, such as Eclipse, will collapse the imports in one line, and you can expand them when needed, so they won't clutter your view

• In case of conflicts, you can always refer to fully qualified classes, but if one of the two classes is under your control, you can consider renaming it. (with Eclipse, right click on the class, choose Refactor -> Rename, it will take care to update all its references).

• If your class is importing from AWT and from your package of shapes, is ok. It's ok to import from several classes; however, if you find yourself importing from really lots of disparate sources, it could be a sign that your class is doing too much, and need to be split up.

Answer 4

It's normal in Java world to have a lot of imports - you really need to import everything. But if you use IDE such as Eclipse, it does the imports for you.

Answer 5

I don't get all the non-answers posted here.

Yes, individual imports are a bad idea, and add little, if anything, of value.

Instead just explicitly import the conflicts with the class you want to use (The compiler will tell you about conflicts between the awt and shapes package.) like this:

import java.awt.*;
import shapes.*;
import shapes.Rectangle; // new Rectangle, and Rectangle.xxx will use shapes.Rectangle.

This has been done for years, since Java 1.2, with awt and util List classes. If you occasionally want to use java.awt.Rectangle, well, use the full class name, e.g., new java.awt.Rectangle(...);.

Answer 6

• If you use glob imports, it's possible to break your code with a namespace clash just by updating a dependency that introduces new types (typically not expected to be a breaking change). It could be a pain to fix in a large codebase that was liberal with their use of glob imports. That is the strongest reason I can think of for why it's a good idea to specify dependencies explicitly.
• It's easier to read code which has each of the imports specified, because you can see where types are coming from without requiring IDE specific features and mouse hovering, or going through large pages of library documentation. Many people read a lot of code outside the IDE in code review, diffs, git history, etc.