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 same names as java.awt classes.

Now, since I do not want to rename every class in my code-base, to show my source files which class I mean when I , say, declare a new Rectangle, I need to either:

1- import the rectangle class explicitly, i.e import shapes.Rectangle

OR

2- import only the java.awt classes I need and not import java.awt.* which automatically includes the awt.Rectangle

Now the problem is that both ways result in a lot of importing, I currently have an average of 15-25 imports in each source file, which is seriously making my code mixed-up and confusing.

Is too many imports in your code a bad thing? Is there any way around this?

Answer 1

• 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 2

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 3

Yes, too many imports is a bad thing because it clutters your code and makes your imports less readable.

Avoid long import lists by using wildcards.

Kevlin Henney talks about this exact Stack Overflow question 27:54 into his presentation Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks from NDC London 16-20 Jan 2017

Answer 4

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! :-)