Import Statements

Once code is organized into packages, you need a way to reference classes that live in a different package than the one you are writing in. The import statement lets you do that by name, instead of typing out the fully-qualified package path every single time you use the class.

Without an Import

You can always refer to a class using its fully-qualified name — the package plus the class name — with no import at all.

Fully-qualified, no import

Java

public class DateDemo {
    public static void main(String[] args) {
        java.time.LocalDate today = java.time.LocalDate.now();
        System.out.println(today);
    }
}

Single-Class Imports

Importing the class once at the top of the file lets you refer to it by its simple name everywhere below, which is far more readable.

Single-class import

Java

import java.time.LocalDate;

public class DateDemo {
    public static void main(String[] args) {
        LocalDate today = LocalDate.now();
        System.out.println(today);
    }
}

Wildcard Imports

A wildcard import brings in every public class from a package at once, using an asterisk in place of a specific class name.

Wildcard import

Java

import java.util.*;

public class CollectionDemo {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        Map<String, Integer> scores = new HashMap<>();
        names.add("Ada");
        scores.put("Ada", 100);
        System.out.println(names + " " + scores);
    }
}

Note

Wildcard imports are functionally identical to importing each class individually — there is no runtime performance difference. Most style guides still discourage them, though, because they hide exactly which classes a file depends on and can cause ambiguous name conflicts if two imported packages define a class with the same name. Many IDEs are configured to automatically expand wildcards into explicit imports on save.

Style	Example	Trade-off
Single-class import	import java.util.List;	Explicit and clear, more lines
Wildcard import	import java.util.*;	Fewer lines, less clear about actual dependencies
Fully-qualified, no import	java.util.List<String>	Verbose, occasionally used to disambiguate name clashes

java.lang Is Always Available

Classes in the java.lang package — including String, Integer, Object, Math, and System — are imported automatically into every Java file. You never need to write import java.lang.String;; it is implicit.

Note

This is why beginners can use String, System.out.println(), and basic exception types like RuntimeException from their very first program without ever writing an import statement.

Static Imports

A regular import brings in a class name; a static import goes a step further and brings in a specific static member, letting you use it without qualifying it with the class name at all.

Static import

Java

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

public class CircleDemo {
    public static void main(String[] args) {
        double radius = 4.0;
        double area = PI * radius * radius;
        System.out.println(area);
        System.out.println(sqrt(16));
    }
}

Tip

Static imports are handy for math-heavy code and for test assertions (for example, assertEquals from JUnit), but use them sparingly — overusing static imports can make it unclear where a bare method name is actually coming from.

import brings a package member into scope by simple name
Single-class imports are the clearest and most common style
Wildcard imports (import java.util.*;) work but obscure exact dependencies
java.lang is imported automatically and never needs an explicit import
import static brings in a specific static member for unqualified use