Sentencia import en Java

Una vez que tu código vive en un paquete, cualquier código fuera de ese paquete debe referirse a tus tipos ya sea por su nombre completamente calificado (com.w3docs.parser.Tokenizer) o importándolos para que el nombre corto sea suficiente. Las importaciones no cargan nada, no copian nada ni afectan al tiempo de ejecución — son una conveniencia puramente en tiempo de compilación que le indica al compilador qué significa Tokenizer en este archivo. Tres variantes cubren todo lo que alguna vez necesitarás: tipo único, bajo demanda (comodín) y estática.

Dónde van los imports

Cada archivo fuente Java sigue el mismo orden fijo:

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

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

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

package primero (si existe), luego los imports, y después las declaraciones de tipos. Cualquier otra cosa es un error de compilación.

Importaciones de tipo único

La forma más común nombra una sola clase:

import java.util.ArrayList;

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

Después del import, cada mención no calificada de ArrayList en el archivo se resuelve como java.util.ArrayList. Aún puedes escribir el nombre completamente calificado en el mismo archivo si alguna vez necesitas desambiguarlo de otro ArrayList en otro lugar.

Importaciones bajo demanda (comodín)

Para traer todo lo de un paquete, usa un *:

import java.util.*;

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

El comodín importa cada clase pública de nivel superior de java.util — pero no los subpaquetes. import java.util.*; no te da nada de java.util.concurrent; eso requiere un import java.util.concurrent.*; separado. Tampoco existe el atajo import java.*; — java en sí mismo no contiene clases, solo subpaquetes.

Un debate de estilo común: las importaciones de tipo único hacen que las dependencias del archivo sean explícitas y legibles; los comodines mantienen el bloque de importaciones corto. Los IDEs manejan ambos sin problemas, así que es principalmente una cuestión de estilo de proyecto. La Guía de Estilo de Java de Google prohíbe los comodines; muchos proyectos de código abierto los permiten. Elige uno y sé consistente.

Importaciones estáticas

Una importación estática trae un miembro static — un método o campo — al ámbito para que puedas llamarlo sin nombrar su clase:

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
}

Las importaciones estáticas brillan en el código de pruebas — assertEquals(...) se lee mejor que Assertions.assertEquals(...) — y en fórmulas matemáticas donde el nombre de la clase es simplemente ruido. Se convierten en un problema cuando se abusa de ellas: quien lea el archivo tiene que rastrear los imports para averiguar de dónde viene un assertThat(...) sin prefijo. Úsalas cuando los nombres de función son bien conocidos e inequívocos en el contexto.

También puedes usar comodines en importaciones estáticas: import static java.lang.Math.*; trae todos los miembros estáticos públicos de Math. Las mismas advertencias sobre claridad aplican.

Qué se importa de forma gratuita

Java importa un par de cosas automáticamente y nunca tienes que escribirlas:

• Cada clase en java.lang — String, Object, Math, Integer, Thread, Throwable, y el resto.
• Cada clase en tu propio paquete.

Por eso puedes usar String y System.out.println sin una línea import. Cualquier otra cosa debe traerse explícitamente.

Resolución de conflictos de nombres

Dos imports para el mismo nombre simple no compilan — java.util.Date y java.sql.Date no pueden importarse ambos en el mismo archivo. La solución es importar uno y calificar el otro:

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();

Una importación de tipo único siempre gana sobre un comodín. Si import java.util.*; e import java.sql.Date; están ambos presentes, un Date sin prefijo significa java.sql.Date — la importación de tipo único explícita tiene precedencia sobre la de demanda, así que este caso compila sin problemas. Solo dos importaciones de tipo único para el mismo nombre simple son un error definitivo.

Este es el mismo problema que el capítulo de paquetes destacó, visto desde el lado de los imports.

Un ejemplo práctico

Este programa importa tipos en las tres formas — única, comodín y estática — y luego verifica en tiempo de ejecución que las clases resultantes son exactamente las de esos paquetes.

Los primeros tres imports cubren todas las formas que tiene el lenguaje. Observa que el comodín import java.util.*; es lo que hace que List, Collections y Date estén disponibles — el import java.util.ArrayList; explícito es redundante en este archivo, pero es el tipo de línea que una guía de estilo de proyecto podría requerir por legibilidad.

Qué sigue

Has visto cómo extraer tipos de los paquetes. A continuación harás el otro lado — declarar tu propio paquete y organizar los archivos para que tanto el compilador como la JVM estén satisfechos. Continúa con creación de paquetes personalizados en Java.

Práctica