Paket importieren. * Vs. Import package.SpecificType

Question

Wäre es ein Unterschied in Bezug auf Overhead, einen Import zu schreiben, der alle Typen innerhalb eines Pakets lädt (import java.*); als nur ein spezifischer Typ (d. h. import java.lang.ClassLoader)? Wäre der zweite besser geeignet als der andere?

Answer 1

Es gibt keine Leistungs- oder Gemeinkosten für den Import. * Vs Importieren bestimmter Typen. Ich halte es jedoch für eine bewährte Methode, den Import niemals zu verwenden. * Mein Hauptgrund dafür ist, dass ich die Dinge geradlinig, sauber und mit so wenig Zweideutigkeiten wie möglich halte, und ich denke, mit einem * Import verlieren Sie das .

Answer 2

Ein guter Grund, niemals den Import xxx zu verwenden. * Ist eine klare Vision von dependencies.

Sie können schneller wissen, dass Sie eine bestimmte Klasse eines anderen Pakets verwenden, da es direkt am Anfang der Quelldatei aufgeführt wird.

Answer 3

Werfen Sie einen Blick auf die Java-API, und Sie werden viele Klassen und Schnittstellen mit demselben Namen in verschiedenen Paketen sehen.

Zum Beispiel:

java.lang.reflect.Array 
java.sql.Array 

Also, wenn Sie importieren java.lang.reflect.* und java.sql.* es eine Kollision auf dem Array-Typ hat, und müssen sie vollständig in Ihrem Code qualifizieren.

Durch den Import bestimmter Klassen sparen Sie sich diesen Aufwand.

Answer 4

Nachdem ich nach weiteren Informationen gesucht habe, bin ich auf diese Website gestoßen, wo sie sehr gut erklärt wird. Import issue und Does using * in an import statement affect performance?.

Gibt es Effizienzprobleme zwischen diesen beiden Stilen? Möglicherweise, aber da Import-Deklarationen nichts in Ihr Programm importieren, ist der Unterschied sehr gering. Denken Sie daran, dass es einen impliziten Import java.lang. * An der Spitze Ihrer Kompilierungseinheiten gibt und java.lang in JDK 1.2.2 75 Klassen und Schnittstellen enthält. Ein Experiment, bei dem ein künstliches Beispiel verwendet wurde, eines mit tausenden Klassennamensverwendungen, die nachgeschlagen werden müssen, zeigte eine vernachlässigbare Änderung der Kompilierungsgeschwindigkeit. Daher sollte die Kompilierungsleistung wahrscheinlich nicht als ein Faktor angesehen werden, wenn ein Format einem anderen gegenübergestellt wird.

Es gibt einen letzten Winkel von Interesse für Importdeklarationen. Angenommen, Sie verwenden eine innere Klasse:

package P; 

public class A { 
    public static class B {} 
} 

Wenn Sie eine von einer anderen Übersetzungseinheit zugreifen möchten, sagen Sie:

import P.*; 

oder: Import P.A; Aber wenn Sie B ohne Qualifikation zugreifen möchten, müssen Sie sagen:

import P.A.*; 

oder: Import P.A.B; Der erste von diesen stellt verfügbare Typen innerhalb der Klasse A im Paket P zur Verfügung. Der zweite stellt nur den Typ B in Klasse A in Paket P zur Verfügung.

Answer 5

Ich neige dazu, zu verwenden, was auch immer der IDE-Standard ist. Ich finde, dass es sich nicht lohnt, sich darüber Gedanken zu machen, da es keine Auswirkungen auf die Performance hat und die Überprüfung von Abhängigkeiten mit einer Vielzahl von Tools gehandhabt werden kann.

Answer 6

Die Importe sind auf Bytecode-Ebene nicht wichtig, daher sollte es keine Laufzeitdifferenz geben.

Ich finde es am besten: a) Seien Sie explizit durch die Auflistung aller Importe b) Lassen Sie Ihre IDE es verwalten. Alle wichtigen IDEs können Ihre Importe automatisch aktualisieren, sortieren und vervollständigen.

Ich habe a) gefunden, um ein paar Mal nützlich zu sein, wenn man manuelle Umpackung außerhalb des Kontexts eines In-IDE-Refactoring macht. Wie zum Beispiel, wenn Marketing den Namen Ihres Produktes ändert und entscheidet, dass alle Ihre Pakete den Namen ändern sollten.

Answer 7

Das ist eigentlich ein sehr schlechtes Problem.

Angenommen, Sie

schreiben

import a.*; 
import b.*; 
... 
Foo f; 

und Klasse Foo existiert ein im Paket.

Jetzt checken Sie Ihren perfekten Kompilierungscode ein und sechs Monate später fügt jemand Klasse Foo zu Paket b hinzu. (Vielleicht ist es eine Third Party Lib, die Klassen in der neuesten Version hinzugefügt hat).

Poof! Jetzt verweigert der Code die Kompilierung.

Nie Verwendung Import-on-Demand. Es ist böse!

Weitere Informationen finden Sie unter http://javadude.com/articles/importondemandisevil.html.

RE Leistung:

import a.*; 

vs

import a.X; 

macht keinen Unterschied zur Laufzeit. Der Compiler stellt die aufgelösten Klassennamen in die generierten .class-Dateien fest.

Answer 8

Ansicht von Minderheit: in meinem Code Ich neige dazu, Tonnen von Klassen aus ein paar Paketen zusammen mit ein paar ungeraden Klassen hier und da zu verwenden. Ich möchte meine Importliste klein halten, damit ich auf einen Blick sehen kann, was passiert. Um dies zu tun, setze ich den Schwellenwert auf 4 Klassen. Darüber hinaus verwendet Eclipse * für meinen Code. Ich finde, dass dies meine Paket-Importe lesbar hält, und ich neige dazu, sie als die erste Sache zu bezeichnen, die ich mache, wenn ich auf eine Klasse schaue, um die Frage zu beantworten: Wem spricht es?

In Bezug auf Name Kollision: Wie sind die Chancen, dass Sie vier oder mehr Klassen aus zwei Paketen importieren, die konkurrierende Klassennamen haben? Wenn es mehr als 10% der Zeit ist, sollten Sie die Anzahl der Pakete berücksichtigen, auf die Ihre Klasse angewiesen ist (z. B. um sie in kleinere Klassen umzuwandeln).

Answer 9

Es ist mehr eine gute Kodierungspraxis, da jeder, der Ihren Code liest, sofort weiß, welche Klassen von einer bestimmten Klasse verwendet werden, indem Sie einfach den Importblock an der Spitze der Datei betrachten, während man graben müsste Sie haben Platzhalter verwendet.

Answer 10

Wenn Sie mehr als 20 Klassen aus demselben Paket importieren, verwenden Sie besser xxx importieren. *. "Clean Code" spricht sich dafür aus, das gesamte Paket ebenfalls zu importieren.