Geschwindigkeits unterschied bei import?

[Defkil]

Hey
ich wollte fragen ob es ein unterschied bei der Ladezeit (Auch wenn es nur MS sind) gibt, wenn man

import java.util.Date;

oder nur

import java.util.*;

schreibt.
Dank im vorraus

 

[Zeigefinger]

Die Gegenfrage!
Warum willst du alles aus dem Kühlschrank auf den Frühstückstisch stellen, wenn du weißt, dass du nur ein Toast mit Marmelade essen willst?

Oder anders: Nur das importieren, was du benutzt. Unabhängig von Ladezeiten und co.

 

[jgh]

nein, das macht keinen Unterschied vom Aufwand des "importieren"...wobei das eigentlich auch falsch ausgedrückt ist.
die

import

-Anweisungen dienen einfach dazu, den Quellcode ein wenig kürzer und übersichtlicher zu gestalten. Der einzige Zweck ist, dass du anstelle von

java.util.Date date = new java.util.Date();

nun auch einfach

Date date = new Date();

schreiben kannst.

Die

import

-Anweisungen mit den [c]import java.util.*[/c] als Wildcard "importiert" nun das ganze Paket, so dass bswp neben dem Date, auch der Calendar, HashMap, HashSet, GregorianCalendar und alle mögliche Klassen, Interfaces usw ohne den kompletten Namen angesprochen werden können.

Grundsätzlich sollte man imho auf die Wildcard

*

verzichten und nur die Klassen importieren, die man auch benutzt.

und mit Ladezeiten hat der [c]import[/c] nichts zu tun...

 

[dev.buzz]

import java.util.Date;

Importiert nur das java.util.Date; Packet.

import java.util.*;

Importiert das gesamte java.util*; Packet.

IMHO ist Date schneller bei´m Laden als das gesamte Packet. Verlass dich nicht auf meine Antwort, bin selbst ein Anfänger. Mal schauen was die Profis dazu sagen.

Tante edit sagt: Danke jgh

 

[jgh]

nochmal...die import-Anweisung lädt keine Pakete im dem Sinne, dass erstmal die importierten Klassen in die VM geladen werden, oder ähnliches!!!

Das ist Unsinn...der einzige Zweck ist, dass man im Quellcode nicht den ganzen Paketnamen nennen muss!!!! Einen Zeitunterschied gibt es nicht!

[edit]Tante Edith sagt bitte [/edit]

 

[Zeigefinger]

Zusätzlich läuft man weniger Gefahr sich Konflikte ins Haus zu holen.

Gibt ja nunmal mehrere Dinge mit dem gleichen Namen und unter Umständen benutzt man dann falsche Klassen, weil man sie schon über .* aus einem anderen Paket geladen hat.

 

[Firephoenix]

Geht in Eclipse übrigens sehr komfortabel mit Strg+Shift+O:
Räumt unbenutzte imports aus der klasse, sucht nach passenden treffern für unbekannte Klassen und bietet bei mehreren treffern einen dialog an wo man die gewünschte auswählen kann - da mal draufgehen bei warnings in den imports oder wenn eine klasse fehlt und man ist (meistens) glücklich

Gruß

 

[WildcardImport]

Wie bereits gesagt wurde macht es überhaupt keinen Unterschied ob man direkt nur die Klassen importiert die man auch verwendet oder deren ganzes Paket. Die import-Anweisungen sind AUSSCHLIEßLICH für den Compiler interessant damit er weis das wenn du "Date" schreibst auch die Klasse "java.util.Date" meinst. Am Ende stehen nämlich im fertigen Class-File ALLE Klassen mit ihrem vollen Package-Namen und die import-Zeilen sind komplett weg.
Das einzige was man beachten muss sind Konflikte wenn es in mehreren Paketen die man über Wildcard importiert Klassen mit dem selben Namen gibt. Beliebtes Beispiel : java.util.Date <-> java.sql.Date. Wenn du beides importierst weis der Compiler nämlich nicht mehr welche Klasse Date du meinst, egal ob du Wildcards nutzt oder nicht. In dem Fall muss man den vollen Klassennamen angeben was man an sich auch so machen könnte und der Compiler am Ende auch macht. Import-Zeilen in Java dienen nur der "Übersichtlichkeit" des Codes und zur Verringerung des Schreibaufwandes. Einen Pre-Compiler wie bei C der alle include-Zeilen durch den jeweiligen Inhalt des Include-File ersetzt und daraus dann schon anfängt das OBJ-File zu basteln gibt es in Java nicht. Wesshalb es auch nur einen Compiler, nicht aber einen Linker gibt. Das macht die VM zur Runtime.

 

[GstGstGstGst]

Das mit dem Stern - Import wird i.a. auch als schlechter Stil angesehen.
Bei etwas komplexeren Programmen kann man schnell mal nicht mehr sicher wissen aus welchem
Paket denn nun eine Klasse mit einem netten Name wie "Date" importiert wurde.
Unter Umständen hat man dann vielleicht den Import mit

import hugo.fritz.*

und dieses Paket kennt eine Klasse namens

Date

.
Die Code-Completion von Eclipse ist glücklich, du als Programmierer auch, aber oh Wunder....
Die Methode von

Date

die du brauchst, fehlt.
Grund:

Java.util.Date

meintest du als Programmierer, hast aber

import hugo.fritz.*

angesprochen.
Und an der Importliste siehst du nicht, daß es

import hugo.fritz.Date

war. Der Stern
"verdeckt" das.
Mit dem direkten Import kann man das sofort an der Importliste erkennen.

...und was das Tempo angeht: zur Laufzeit ist das völlig egal, weil da die Klassen schon alle zusammengebunden sind. Der Einzige dem die Imports nutzen/helfen ist der Programmierer.
Gründe: siehe meine Vorredner.

 

[bygones]

mich wundert wer alles heute in IDEs noch die import Anweisungen anschaut.... ist doch wurscht ob nun der import per stern oder nicht importiert wird. Wenn man entwickelt ist man in der IDE und da gibt es bessere wege als die import anweisungen zu durchforsten.

 

[WildcardImport]

screw IDE ... Notepad2 + Console FTW

Ne erlich : nur weil man selbst als Anfänger mit ner IDE angefangen hat (ist schon mal der erste große Fehler) und/oder damit selbst arbeitet muss man das nicht auf andere projezieren oder es ihnen gar vorschreiben. Und wenn man halt mit nem Editor und nem Terminal arbeitet *was IMO einfacher ist* dann kann sowas schon mal wichtig werden.

 

[Schandro]

Hey
ich wollte fragen ob es ein unterschied bei der Ladezeit (Auch wenn es nur MS sind) gibt, wenn man

import java.util.Date;

oder nur

import java.util.*;

schreibt.
Dank im vorraus

Sich über performanceoptimierung am Anfang überhaupt Gedanken zu machen ist komplette Zeitverschwendung, denn meistens führt das nur dazu das Codestellen die entweder keinerlei oder nur Auswirkungen im nanosekundenbereich haben "optimiert" werden anstatt die Sachen zu optimieren die tatsächlich unnötig lange brauchen.

 

[WildcardImport]

Sich über performanceoptimierung am Anfang überhaupt Gedanken zu machen ist komplette Zeitverschwendung, denn meistens führt das nur dazu das Codestellen die entweder keinerlei oder nur Auswirkungen im nanosekundenbereich haben "optimiert" werden anstatt die Sachen zu optimieren die tatsächlich unnötig lange brauchen.

[drastische Kritik, dass das gar nicht das Thema wäre]

 

[SlaterB]

@WildcardImport
halte dich bisschen zurück, falls du deine Postings auch dauerhaft sehen willst,
und dir nicht ausreicht bisschen zu poltern bis sie entfernt werden

unabhängig davon, dass es hier nichts zu optimieren gibt, ist der Hinweis, sich nicht um Micro-Optimierungen zu kümmern, absolut hilfreich,
denn wenn erstmal diese Einstellung 'geläutert' ist, käme es gar nicht zu diesem Pseudo-Problem sowie zu weiteren ähnlichen