Die import-Deklaration informiert den Compiler über die Pakete, sodass ein Typ nicht mehr voll qualifiziert werden muss, wenn er im import-Teil explizit aufgeführt wird oder wenn das Paket des Typs über * genannt ist.
Falls eine Klasse statische Methoden oder Konstanten vorschreibt, werden ihre Eigenschaften immer über den Typnamen angesprochen. Java bietet mit dem statischen Import die Möglichkeit, die statischen Methoden oder Variablen ohne vorangestellten Typnamen sofort zu nutzen. Während also das normale import dem Compiler Typen benennt, macht ein statisches import dem Compiler Klasseneigenschaften bekannt, geht also eine Ebene tiefer.
Beispiel: Binde für die Bildschirmausgabe die statische Variable out aus System statisch ein:
import static java.lang.System.out;
Bei der sonst üblichen Ausgabe über System.out.printXXX(…) kann nach dem statischen Import der Klassenname entfallen, und es bleibt beim out.printXXX(…)
Bilden wir in einem Beispiel mehrere statische Eigenschaften mit einem statischem import ein:
import static java.lang.System.out;
import static javax.swing.JOptionPane.showInputDialog;
import static java.lang.Integer.parseInt;
import static java.lang.Math.max;
import static java.lang.Math.min;
class StaticImport {
public static void main( String[] args ) {
int i = parseInt( showInputDialog( "Erste Zahl" ) );
int j = parseInt( showInputDialog( "Zweite Zahl" ) );
out.printf( "%d ist größer oder gleich %d.%n",
max(i, j), min(i, j) );
}
}
Mehrere Typen statisch importieren
Der statische Import
import static java.lang.Math.max; import static java.lang.Math.min;
bindet die statische max(…)/min(…)-Methode ein. Besteht Bedarf an weiteren statischen Methoden, gibt es neben der individuellen Aufzählung eine Wildcard-Variante:
import static java.lang.Math.*;
Best Practice: Auch wenn Java diese Möglichkeit bietet, sollte der Einsatz maßvoll erfolgen. Die Möglichkeit der statischen Importe ist nützlich, wenn Klassen Konstanten nutzen wollen, allerdings besteht auch die Gefahr, dass durch den fehlenden Typnamen nicht mehr sichtbar ist, woher die Eigenschaft eigentlich kommt und welche Abhängigkeit sich damit aufbaut. Auch gibt es Probleme mit gleichlautenden Methoden: Eine Methode aus der eigenen Klasse überdeckt statische importierte Methoden. Wenn also später in der eigenen Klasse – oder Oberklasse – eine Methode aufgenommen wird, die die gleiche Signatur hat wie eine statisch importierte Methode, wird das zu keinem Compilerfehler führen, sondern sich die Semantik ändern, weil jetzt die neue eigene Methode verwendet wird, und nicht mehr die statisch importierte.