[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.736. 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.737. 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. When disabled, the declarations are printed in their original order.

Sort Order

Lets you control the sorting order and grouping behavior of import declarations. When sorting is enabled, import declarations will be sorted according to the positions of the package names as specified in the list component. To specify the order in which the declarations should appear, you can use the Up and Down buttons.

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

If you want to change an existing grouping definition, you can do so by selecting the definition you want to change 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 just double-clicking with the mouse on the grouping definition you want to change.

Figure 2.61. Change existing Grouping Definition

Change existing Grouping Definition

Note that the * that represents all undefined packages, cannot be changed (you can only adjust the grouping depth).

Grouping

In addition to sorting, associated declarations can 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.

Via the grouping depth you can 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.738. 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.739. 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.740. 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.741. Mixed static/standard import declarations

import java.awt.BorderLayout;

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

import z.Foo;

Example 2.742. Static import declarations placed above

import static javax.swing.WindowConstants;

import java.awt.BorderLayout;

import javax.swing.SwingUtilities;

import z.Foo;

Example 2.743. 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.

Tip

Sorting (see Section 2.8.12.1, “Sort imports”) should be enabled when different IDEs are used, as otherwise implementation details may yield to differences regarding import placement.

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.744. On-demand import declaration

import java.util.*;

could become

Example 2.745. 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.

Use custom implementation

The IDE Plug-ins usually leverage the build-in import optimization facility, but sometimes these may contain bugs that prevent their usage. Here, you can enable a custom implementation instead. It’s the same implementation that is used by the non-IDE Plug-ins.

Note

Please note that the custom import optimization implementation only supports expanding on-demand imports

Since 1.7

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.746. 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.747. 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.748. 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.