Why You Should Avoid Wildcard Imports (*) in Java

If you’ve written Java for a while, you’ve probably seen both of these styles:

import java.util.\*;

and

import java.util.List;
import java.util.Map;
import java.util.Set;

At first glance, wildcard (*) imports might look cleaner — fewer lines, less typing. But in professional Java development, explicit imports are almost always better. Here’s why.

1. Clarity Over Brevity

With wildcard imports, you can’t tell at a glance which specific classes a file depends on.

import java.util._;
import java.sql._;

If you later see this line:

Date date = new Date();

is it java.util.Date or java.sql.Date?
You have to check — or worse, wait for the compiler to complain.

Explicit imports make this obvious:

import java.util.Date;

Now you know immediately where it’s coming from.

2. Avoid Name Conflicts

Different packages often contain classes with the same name (List, Date, Timer, etc.).
Wildcard imports can silently introduce conflicts when new dependencies are added.

If your codebase grows or someone adds a new import later, that simple * can break previously valid code.

3. Better for Code Reviews and Refactoring

When you review code or refactor old files, explicit imports tell you exactly what’s used — no guesswork required. It also makes automated refactoring tools (and IDEs) behave more predictably.

Wildcard imports, on the other hand, hide dependencies. That makes your file’s surface area less visible and increases the mental load of understanding it.

4. Modern IDEs Do the Work for You

The only argument for * imports was “less typing.”
That’s irrelevant today — IntelliJ IDEA, Eclipse, and VS Code can:

• Automatically add imports as you type

• Remove unused ones

• Optimize imports on save (Ctrl + Alt + O in IntelliJ)

You get explicit imports without any extra effort.