W3docs

Istruzione import in Java

Porta i tipi nell'ambito in Java con istruzioni import, import con wildcard e import statici.

Una volta che il codice si trova in un package, tutto ciò che scrivi al di fuori di quel package deve fare riferimento ai tuoi tipi con il loro nome completo (com.w3docs.parser.Tokenizer) oppure importandoli, in modo che basti il nome breve. Le importazioni non caricano nulla, non copiano nulla e non influenzano l'esecuzione — sono una pura comodità in fase di compilazione che dice al compilatore cosa significa Tokenizer in questo file. Tre varianti coprono tutto ciò di cui avrai mai bisogno: singolo tipo, on-demand (wildcard) e static.

Dove vanno le importazioni

Ogni file sorgente Java segue lo stesso ordine fisso:

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

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

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

Prima package (se presente), poi import, poi le dichiarazioni di tipo. Qualsiasi altra cosa è un errore di compilazione.

Import a tipo singolo

La forma più comune nomina una sola classe:

import java.util.ArrayList;

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

Dopo l'importazione, ogni menzione non qualificata di ArrayList nel file viene risolta in java.util.ArrayList. Puoi comunque scrivere il nome completo nello stesso file se hai mai bisogno di disambiguarlo da un altro ArrayList altrove.

Import on-demand (wildcard)

Per includere tutto da un package, usa *:

import java.util.*;

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

Il wildcard importa ogni classe pubblica di primo livello di java.util — ma non i sottopackage. import java.util.*; non ti fornisce nulla da java.util.concurrent; quello richiede un import java.util.concurrent.*; separato. Non esiste nemmeno la scorciatoia import java.*;java stesso non contiene classi, solo sottopackage.

Un dibattito stilistico comune: gli import a tipo singolo rendono le dipendenze del file esplicite e leggibili; i wildcard mantengono breve il blocco delle importazioni. Gli IDE gestiscono entrambi senza problemi, quindi è principalmente una scelta stilistica del progetto. La Google Java Style Guide vieta i wildcard; molti progetti open source li consentono. Scegline uno e sii coerente.

Import statici

Un import static porta un membro static — un metodo o un campo — nell'ambito, così puoi chiamarlo senza nominare la sua classe:

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
}

Gli import statici sono utili nel codice di test — assertEquals(...) si legge meglio di Assertions.assertEquals(...) — e nelle formule matematicamente intensive in cui il nome della classe è solo rumore. Diventano un problema se usati in eccesso: chi legge il file deve scorrere le importazioni per capire da dove viene un semplice assertThat(...). Usali quando i nomi delle funzioni sono noti e non ambigui nel contesto.

Puoi usare il wildcard anche negli import statici: import static java.lang.Math.*; include tutti i membri statici pubblici di Math. Si applicano le stesse avvertenze sulla chiarezza.

Cosa viene importato gratuitamente

Java importa automaticamente alcune cose e non devi mai scriverle:

  • Ogni classe in java.langString, Object, Math, Integer, Thread, Throwable e le altre.
  • Ogni classe nel tuo stesso package.

Ecco perché puoi usare String e System.out.println senza una riga import. Tutto il resto deve essere incluso esplicitamente.

Risoluzione dei conflitti di nomi

Due importazioni per lo stesso nome semplice non compilano — java.util.Date e java.sql.Date non possono essere entrambe importate nello stesso file. La soluzione è importarne una e qualificare l'altra:

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

Un import a tipo singolo vince sempre su un wildcard. Se import java.util.*; e import java.sql.Date; sono entrambi presenti, un Date senza qualifica significa java.sql.Date — l'import esplicito a tipo singolo ha la precedenza su quello on-demand, quindi questo caso compila senza problemi. Solo due import a tipo singolo per lo stesso nome semplice costituiscono un errore definitivo.

Questo è lo stesso problema evidenziato nel capitolo sui package, visto dal lato delle importazioni.

Un esempio pratico

Questo programma importa tipi in tutte e tre le forme — singolo, wildcard, static — e verifica a runtime che le classi risultanti siano esattamente quelle di quei package.

java— editable, runs on the server

Le prime tre importazioni coprono ogni forma che il linguaggio offre. Nota che il wildcard import java.util.*; è ciò che rende disponibili List, Collections e Date — l'import java.util.ArrayList; esplicito è ridondante in questo file, ma è il tipo di riga che una guida stilistica di progetto potrebbe richiedere per leggibilità.

Cosa c'è dopo

Hai visto come estrarre tipi dai package. Ora farai l'altro lato — dichiarare il tuo package e organizzare i file in modo che sia il compilatore sia la JVM siano soddisfatti. Continua con creazione di package personalizzati in Java.

Esercizi

Pratica
Cosa porta effettivamente nell'ambito `import java.util.*;`?
Cosa porta effettivamente nell'ambito `import java.util.*;`?
Was this page helpful?