[Skip to content]

2.8.12. Imports

Controls the handling of import declarations. With Java, import declarations are used to make types available within a compilation unit. There are two types of import declarations:

Single-type imports import a single named type.

Example 2.746. Single-type imports

import java.util.ArrayList;
import java.util.List;

On-demand imports import all accessible types declared in the type or package.

Example 2.747. On-demand imports

import java.util.*;
import java.util.regex.*

Figure 2.59. Imports settings page

Imports settings page

2.8.12.1. General

Lets you control the general imports settings.

Sort imports

Enables or disables the sorting of import declarations. Enabling this option will sort all declarations lexicographically. When disabled, import declarations are printed in their original order.

Sort Order

When sorting is enabled, import declarations will be sorted according to the order of the package names as specified in the list component. To control the order in which the declarations should appear, you can use the Up and Down buttons to move the corresponding entries up and down.

You can add/remove package names (e.g. javax, javax.swing or com.foo.sarah) to and from the list via the Add... and Remove buttons. A dialog appears that lets you add a new grouping definition. The star character (*) represents all undefined packages and cannot be removed.

Figure 2.60. Add new Grouping Definition

Add new Grouping Definition

A grouping definition consists of a package name and a grouping depth that defines how many parts of the name should be significant for grouping (see “Grouping” below for more information).

If you want to change an existing grouping definition, you can do so by selecting an entry in the list, and pressing the Change... button. A dialog appears that lets you change an existing grouping definition. Alternatively, you can invoke the dialog by double-clicking on a grouping definition.

Figure 2.61. Change existing Grouping Definition

Change existing Grouping Definition

Please note that the * character represents all packages not explicitly defined. It cannot be removed, and you can only adjust its grouping depth.

Grouping

In addition to sorting, declarations may be grouped together to reduce complexity by packing related information into a common unit. Grouping means that associated declarations are separated by one blank line. Grouping only happens if sorting is enabled.

The grouping depth lets you control how many parts of a package name should be considered when determine whether two import declarations are to be grouped together. Grouping only happens when all relevant parts are equal. So via the grouping depth you can effectively specify how many package name parts are relevant.

Default grouping depth

This switch lets you define the default grouping depth that should be used when no grouping depth was defined for a specific package name (see below). To disable grouping at all, set the default grouping depth to '0'.

Example 2.748. Grouping depth == 1

import java.awt.Color;
import java.awt.Component;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.ArrayList;
import java.util.List;

Only the first part of the package name will be used to determine grouping.

Example 2.749. Grouping depth == 2

import java.awt.Color;
import java.awt.Component;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import java.util.ArrayList;
import java.util.List;

The first two parts of the package name will be used to determine grouping.

Example 2.750. Grouping depth == 3

import java.awt.Color;
import java.awt.Component;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import java.util.ArrayList;
import java.util.List;

The first three parts of the package name will be used to determine grouping.

Group static imports

To better differ between standard import declarations and the static imports introduced in J2SE 5.0, you can control whether static imports should be grouped separately. You can select whether static import declarations should be printed together with the standard import declarations (“Never”) or placed above (“Top”) or below (“Bottom”) all standard import declarations.

Since 1.4

Example 2.751. Mixed static/standard import declarations

import java.awt.BorderLayout;

import javax.swing.SwingUtilities;
import static javax.swing.WindowConstants;

import z.Foo;

Example 2.752. Static import declarations placed above

import static javax.swing.WindowConstants;

import java.awt.BorderLayout;

import javax.swing.SwingUtilities;

import z.Foo;

Example 2.753. Static import declarations placed below

import java.awt.BorderLayout;

import javax.swing.SwingUtilities;

import z.Foo;

import static javax.swing.WindowConstants;

2.8.12.2. Optimization

Lets you optimize the import declarations by either expanding or collapsing them, obsolete or unused imports are removed.

Note

When using either one of the Ant, Console or Maven plug-ins, you have to explicitly configure the class path for this feature to work. Please refer to the documentation of the individual plug-ins to learn how one can accomplish this (see Part II, “Plug-ins”)

Expand on-demand imports

When enabled, tries to expand all on-demand import declarations. Expanding means to resolve all on-demand imports (sometimes called wildcard imports) and replace them with single-type imports (sometimes called explicit imports) of the types that are actually used in the source file.

Single-type imports have several advantages and should be preferred over on-demand imports.

  • They avoid any class path conflicts that could break your code when a class is added to a package you import

  • They make dependencies explicit, so that anyone who has to read your code later knows what you meant to import and what you didn’t mean to import

  • They can make some compilation faster, because the compiler doesn’t have to search the whole package to identify dependencies, though this is usually not a huge deal with modern compilers

Example 2.754. On-demand import declaration

import java.util.*;

could become

Example 2.755. Single-type import declarations

import java.util.ArrayList;
import java.util.List;

In the examples above, the on-demand import declaration has been expanded into two single-type import declarations that reference the needed types for this package.

Collapse single-type imports

When enabled, tries to collapse all single-type declarations. Collapsing means to remove all single-type imports of a given package and replace them with one on-demand import declaration.

Example 2.756. Single-type import declarations

import java.awt.event.MouseEvent;
import javax.swing.JButton;
import javax.swing.JTable;
import javax.swing.JTextField;

could become

Example 2.757. On-demand import declarations

import java.awt.event.*;
import javax.swing.*;

Please note that there might be collisions that prevent collapsing when two types have the same name.

Example 2.758. Single-type import declarations

import java.awt.Color;
import java.util.List;

In the example above, collapsing both packages is not possible because this would lead to invalid code, as both java.awt and java.util contain a type named List. In such cases only one package will be collapsed (if no further conflicts are detected).

Note

The NetBeans plug-in currently does not support import collapsing