Frage zu der import Anweisung in Java

[DennisXX]

Hallo !!

Ich verstehe nicht ganz, weshlab ich in Java mithilfe der importanweisung solche Paketimporte zwingend durchführen muss:

import java.rmi.*;
import java.rmi.server.*;


Würde es hier nicht ausreichen, einfach nur

import java.rmi.*;

zu schreiben und somit auch sicherzustellen, dass alle Klassen aus java.rmi.server automatisch verfügbar sind?

mfg
Dennis

 

[faetzminator]

Wie du selbst erkennen kannst: nein. Wenn man ein gesamtes Package mit "*" importiert, macht man dies nicht für die Subpackages.

 

[Antoras]

Du hast Packages a.b.bb und a.c.cc usw. Wenn du jetzt mit a.* alle importieren könntest, was würde dann ein Package-System bringen?

 

[Gast2]

Die packages

java.rmi

und

java.rmi.server

haben nichts gemeinsam, außer dass sie zufällig im selben Ordner auf dem Dateisystem liegen.

 

[tuttle64]

Auf den ersten Blick scheint es umständlich zu sein. Wenn man aber davon ausgeht, dass eine Klasse in verschiedene Pakete existieren kann, ist diese Praxis eine gute Massnahme um Namenskonflikte zu vermeiden. Selbst wenn keine Namenskonflikte auftreten, zeugt ein Import mit Wildcards von einem schlechten Programmierstil.

 

[irgendjemand]

mal als beispiel

es gibt einmal [c]java.util.Date[/c] und dann noch [c]java.sql.Date[/c] ... beide haben unterschiedliche aufgaben
wenn man in der API liest dann sieht man das [c]java.sql.Date[/c] von [c]java.util.Date[/c] erbt ... tut aber jetzt nichts zur sache

stell dir mal vor [c]import java.*;[/c] würde auch rekursiv alle sub-packages laden ... dann hätte der compiler auf einmal zwei klasse mit dem namen Date ...
natürlich kann man jetzt bei jedem call den kompletten namen der klasse *also auch mit packages* angeben ... aber um genau das nicht machen zu müssen hat man [c]import[/c] ... ansonsten bräuchte man es nicht ...

wenn der compiler *und am ende auch die VM* jetzt also mit zwei klassen gleichen namens konfrontiert werden ... ohne das eine explizite angabe von packages vorhanden wäre ... wüsste keiner mehr ob du nun [c]java.util.Date[/c] oder [c]java.sql.Date[/c] verwenden willst ... worauf hin du natürlich eine entsprechende fehlermeldung bekommst ...

und genau darum werden mit import keine sub-packages geladen ... ansonsten bräuchte man wie gesagt auch keine import-anweisung da man eh immer den kompletten package-pfad angeben müsste um dem compiler zu sagen welche klassen er verwenden soll ...

 

[DontKnowJava]

stell dir mal vor [c]import java.*;[/c] würde auch rekursiv alle sub-packages laden ... dann hätte der compiler auf einmal zwei klasse mit dem namen Date ...

Und ist das auch der Grund warum nicht automatisch (durch die IDE oder den Compiler) zumindest die Java-eigenen Pakete importiert werden?!

Ich habe mich schon immer gewundert warum man immer noch import Anweisungen überhaupt machen muss und das bei immer ausgefeilteren IDEs und Compilern nicht automatisch übernommen wird.

Wenigstens verstehe ich das jetzt, auch wenn ich es ehrlichgesagt immer noch altertümlich finde :autsch:

 

[faetzminator]

Ich habe mich schon immer gewundert warum man immer noch import Anweisungen überhaupt machen muss und das bei immer ausgefeilteren IDEs und Compilern nicht automatisch übernommen wird.

Du kannst z.B. in Eclipse mit einer Tastenkombi (Ctrl + Shift + O wenn ich mich nicht täusche) die Imports erledigen lassen. Die Imports werden automatisch eingefügt, wenn nur eine Klasse zur Verfügung steht. Des weitern kann man Save Actions definieren, also Aktionen, die gemacht werden, wenn man eine Datei speichert. Dort kann man natürlich ebenfalls organize Imports, Format Code etc. auswählen. Insofern tun das die IDEs ziemlich gut

 

[DontKnowJava]

...Insofern tun das die IDEs ziemlich gut

Mea Culpa :autsch: dann hat die IDE mich schon überholt und ist tatsächlich schon besser als ich es mitbekommen habe :applaus:

...aber ich lerne noch

 

[irgendjemand]

das einzige package was man in java NICHT importieren muss ist java.lang ... und das ist auch das einzige ... keine sub-packages ... keine anderen packages ... nur dieses ...

das liegt unter anderem auch daran das in diesem package klassen wie Object, Class, System, Runtime, Thread, Throwable *sowie davon abgeleitet Exception und Error* und der ganze andere sprach-definierende kram liegt ...
dieses package zeichnet die struktur von java aus ... und ist daher ein zwingender bestandteil einer jeden klasse *da am ende alles von Object erbt *selbst Class** ...

alles andere musst du manuell über imports angeben ...

dabei gibt es einen unterschied ob du gleich ein ganzes package importierst ... oder nur einzelne klassen ... was gerade bei den oben erwähnten namenskonflikten wichtig ist

was IDEs angeht : ich verwende zwar selbst keine ... aber jede IDE ist seit ur-zeiten dazu in der lage imports automatisch zu generieren ...

 

[tuttle64]

stell dir mal vor [c]import java.*;[/c] würde auch rekursiv alle sub-packages laden

Mit import wird gar nichts geladen. Es wird lediglich der Namensraum einer Klasse angegeben. Stellt Dir vor, Du möchtest diese Anweisung verwenden:

out.printf("hallo");

out kennt der Compiler nicht, ausser man gibt mit import an, wo die Klasse liegt:

import static java.lang.System.out;

Nun ist für den Compiler die Welt wieder in Ordnung.

 

[irgendjemand]

1) static imports verwende ich grundsätzlich nicht
2) printf nutze ich ebenfalls grundsätzlich nicht
3) du hast zwar recht das zur compile time ein import dem compiler lediglich einen namensraum eröffnet ... zur runtime jedoch gibt diese anweisung an welche klasse von der VM konkret zu laden sind ... ergo : wenn man java.* schreiben würde und das ganze wäre rekursiv ... dann wäre das ein befehl an die VM um etwas zu LADEN ...

*um es dir vllt noch genauer zu sagen was ich meine : auch der "compiler" ist nur ein weiteres konstrukt von java-klassen die in einer VM laufen ... und wenn dort der parser für syntax durch ist und es ans compilen geht sind die import anweisung für die VM in der gerade die compiler-klassen laufen ebenfalls ein "lade" befehl damit die VM die klassen laden kann um zu wissen was da wie compiled wird ... vielleicht ist es dir jetzt ersichtlicher warum ich das wort "laden" verwendet habe*

 

[Gast2]

wenn man java.* schreiben würde und das ganze wäre rekursiv ... dann wäre das ein befehl an die VM um etwas zu LADEN ...

Nein das stimmt so nicht. Der Compiler ersetzt alle wildcard imports durch imports für die konkreten Klassen die genutzt werden. Importierts du beispielsweise

java.util.*

, nutzt aber nur die Klassen Random und Date, dann ersetzt der Compiler deinen wildcard import durch

java.util.Random

und

java.util.Date

. Es werden also schlussendlich nur die Klassen geladen die du auch wirklich nutzt, und nicht alles.

 

[irgendjemand]

Nein das stimmt so nicht. Der Compiler ersetzt alle wildcard imports durch imports für die konkreten Klassen die genutzt werden. Importierts du beispielsweise

java.util.*

, nutzt aber nur die Klassen Random und Date, dann ersetzt der Compiler deinen wildcard import durch

java.util.Random

und

java.util.Date

. Es werden also schlussendlich nur die Klassen geladen die du auch wirklich nutzt, und nicht alles.

gut ... mach das ganze mal umgekehrt ...
lass dir von deiner IDE mal ein riesen import aus z.b. javax.swing bauen ... also in dem du eine gui mit richtig viel kram zu müllst ...

weist du was der compiler dann aus den 30 zeilen javax.swing.... imports macht ? genau 1 zeile javax.swing.* ... kuggs dir mit JAD an ...

*wenn man schon so klug-s*****t ... sollte man auch wenigstens beide seiten kennen*

 

[tfa]

weist du was der compiler dann aus den 30 zeilen javax.swing.... imports macht ? genau 1 zeile javax.swing.

Nö, der Compiler schmeißt die alle raus, bzw. ersetzt sie (wie bereits gesagt, siehe EikeB). Im Bytecode gibt es keine imports. Wenn ein Decompiler freundlicherweise die imports wieder erscheinen lässt, ist das eine andere Frage.

 

[faetzminator]

weist du was der compiler dann aus den 30 zeilen javax.swing.... imports macht ? genau 1 zeile javax.swing.* ... kuggs dir mit JAD an ...

Davon ausgegangen, dass dies wahr wäre: was würde denn passieren, wenn ich 30 [c]javax.swing[/c] Imports hätte, aber noch eine Klasse, welche es mit diesem Namen gibt, aus [c]ch.faetzminator.foo.gui[/c]? Das wär gar nicht kompilierbar, da dann der Compiler nicht wüsste, ob ich nun [c]javax.swing.Bar[/c] oder [c]ch.faetzminator.foo.gui.Bar[/c] verwenden wollen würde.