Java import Statement

Once your code lives in a package, anything you write outside that package has to refer to your types either by their fully-qualified name (com.w3docs.parser.Tokenizer) or by importing them so the short name is enough. Imports don't load anything, copy anything, or affect runtime — they're a purely compile-time convenience that tells the compiler what Tokenizer means in this file. Three flavors cover everything you'll ever need: single-type, on-demand (wildcard), and static.

Where imports go

Every Java source file follows the same fixed order:

package com.w3docs.parser;          // optional: at most one

import java.util.List;              // zero or more imports
import java.util.Map;

public class Tokenizer { /* ... */ }

package first (if any), then imports, then type declarations. Anything else is a compile error.

Single-type imports

The most common form names one class:

import java.util.ArrayList;

ArrayList<String> names = new ArrayList<>();

After the import, every unqualified mention of ArrayList in the file resolves to java.util.ArrayList. You can still write the fully-qualified name in the same file if you ever need to disambiguate it from another ArrayList somewhere.

On-demand (wildcard) imports

To pull in everything from a package, use a *:

import java.util.*;

List<String> names = new ArrayList<>();
Map<String, Integer> counts = new HashMap<>();

The wildcard imports every public top-level class of java.util — but not subpackages. import java.util.*; does not give you anything from java.util.concurrent; that needs a separate import java.util.concurrent.*;. There's also no import java.*; shortcut — java itself contains no classes, only subpackages.

A common style debate: single-type imports make the file's dependencies explicit and readable; wildcards keep the import block short. IDEs handle both painlessly, so it's mostly a project-style choice. The Google Java Style Guide forbids wildcards; many open-source projects allow them. Pick one and be consistent.

Static imports

A static import brings a static member — a method or field — into scope so you can call it without naming its class:

import static java.lang.Math.PI;
import static java.lang.Math.sqrt;

double hypotenuse(double a, double b) {
  return sqrt(a * a + b * b);   // not Math.sqrt
}

Static imports shine in test code — assertEquals(...) reads better than Assertions.assertEquals(...) — and in math-heavy formulas where the class name is just noise. They become a problem when overused: a reader of the file has to chase imports to figure out where a bare assertThat(...) comes from. Use them when the function names are well-known and unambiguous in context.

You can wildcard static imports too: import static java.lang.Math.*; pulls in every public static of Math. The same caveats about clarity apply.

What's imported for free

Java imports a couple of things automatically and you never have to write them:

• Every class in java.lang — String, Object, Math, Integer, Thread, Throwable, and the rest.
• Every class in your own package.

That's why you can use String and System.out.println without an import line. Anything else needs to be brought in explicitly.

Resolving name conflicts

Two imports for the same simple name don't compile — java.util.Date and java.sql.Date can't both be imported into the same file. The fix is to import one and qualify the other:

import java.util.Date;            // imported short

// Use java.sql.Date by its full name where it appears:
java.sql.Date dbDate = resultSet.getDate(1);
Date now = new Date();

This is the same problem the packages chapter highlighted, viewed from the import side.

A worked example

This program imports types in all three forms — single, wildcard, static — and then verifies at runtime that the resulting classes are exactly the ones from those packages.

The first three imports cover every form the language has. Notice that the wildcard import java.util.*; is what makes List, Collections, and Date available — the explicit import java.util.ArrayList; is redundant in this file, but it's the kind of line a project style guide might require for readability.

What's next

You've seen how to pull types out of packages. Next you'll do the other side — declaring your own package and laying the files out so both the compiler and the JVM are happy. Continue to creating custom packages in Java.

Practice