3
\$\begingroup\$

I am learning java and browsing posts on CodeReview and StackOverflow.

In my text Introduction to Java Programming- Y Daniel Liang it states:

The wildcard import imports all classes in a package by using ...
The information for the classes in an imported package is not read in at compile time or runtime unless the class is used in the program. The import statement simply tells the compiler where to locate the classes. There is no performance difference between a specific and a wildcard import declaration.

These are two examples:

This question: (1)

import java.util.ArrayList;
import java.util.List;
import javafx.beans.value.ChangeListener;
import javafx.beans.value.ObservableValue;
import javafx.collections.FXCollections;
import javafx.collections.ObservableList;
import javafx.geometry.Bounds;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.ListCell;
import javafx.scene.control.ListView;
import javafx.scene.control.ScrollPane;
import javafx.scene.control.TitledPane;
import javafx.scene.layout.AnchorPane;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
import javafx.util.Callback;

This answer: (2)

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;

Could these be written as:

(1)

import java.util.*
import javafx.beans.*
import javafx.collections.*
import javafx.geometry.*
import javafx.scene.*
import javafx.stage.*

and

(2)

import java. util.*

Are there exceptions to using the wildcard for importing?
What is considered the best practice when specifying imports?

I am not sure if this is best posted on code review or stackoverflow

\$\endgroup\$
1
  • 5
    \$\begingroup\$ I'm not sure, but I think this question would be better suited for Programmers. \$\endgroup\$
    – Bobby
    Commented Sep 25, 2013 at 7:21

3 Answers 3

7
\$\begingroup\$

First, let's acknowledge that this is a subjective question. However, in my opinion, it is constructive enough to be on topic for this site.

I would treat the standard Java library differently than your own packages or third-party packages. Everyone recognizes classes from the standard Java library, such as BufferedReader, PrintWriter, and IOException. There is therefore no value in importing those individually; it just clutters the code. Everyone who has worked with Java will know that those classes belong to the java.io package, unambiguously. Anyone who writes classes whose names conflict with those well known classes will be soundly beaten up, so name conflicts with java. classes just don't happen in practice.

With third-party libraries, it makes sense to import more specifically. Programmers encountering those classes could use some help to figure out which packages they belong to. Name clashes could happen. That said, star imports for third-party libraries would be a judgement call. I would suggest importing individual classes up to some number of classes (around 4) per package; beyond that, a star import might be sensible. I would try to avoid star-importing more than one such package, though, to mitigate against the documentation-searching and name clash concerns. (If you feel the urge to star-import multiple packages, your class is probably doing too much anyway and should be split up.)

With code that you have written yourself for the same or a closely related project, go ahead and star-import related packages, judiciously. If you're working with the source code, you'll be familiar with the related code in neighbouring packages anyway. If it fails to compile because of a name clash, you can fix it yourself.

\$\endgroup\$
2
  • \$\begingroup\$ By all means, feel free to wait for responses to roll in before you decide to accept. \$\endgroup\$ Commented Sep 25, 2013 at 9:05
  • \$\begingroup\$ The problem with this is that you assume the programmer writes imports themselves (since AFAIK no IDE can do what you describe). I guess that without the possibility to do selective star imports automaticaly, the arguments against stars imports IMHO prevail. The times when I knew what class is where are long gone and I don't care, that's Eclipse's job. \$\endgroup\$
    – maaartinus
    Commented Jul 26, 2015 at 6:12
3
\$\begingroup\$

I prefer not to use star imports, because they can lead to ambiguities. Read more here: https://stackoverflow.com/a/147461/660143

There is no consensus about whether star import are good or bad. My IDE organizes the imports for me, so I don't care if there are a lot of import statements in my code. But that's my personal opinion.

\$\endgroup\$
1
  • 3
    \$\begingroup\$ There is no consensus about whether star import are good or bad. My IDE organizes the imports for me, so I don't care if there are a lot of import statements in my code. But that's my personal opinion. \$\endgroup\$ Commented Sep 25, 2013 at 7:15
3
\$\begingroup\$

You have a misconception

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;

can't be write like

import java.util.*;

*(wildcard) only imports all the classes from the package, but it doesn't import all the packages inside the package, if that was possible then we can just say

import java.*;

But that's not right.

\$\endgroup\$
2
  • \$\begingroup\$ that is precisely why I wrote this question.. +1 ty \$\endgroup\$
    – user90823
    Commented Sep 25, 2013 at 16:08
  • \$\begingroup\$ @YvetteColomb its not clear that's what you're asking. I needed to see Anirban's comment to understand this constraint \$\endgroup\$
    – caduceus
    Commented Mar 5, 2019 at 6:14