Java-Paketstruktur im Vergleich zur Ordnerstruktur

Question

Alle Java-Projekte, die ich gesehen habe, verwenden eine Ordnerstruktur, die der Paketstruktur folgt. Dies führt zu einer großen Anzahl von Ordnern, die keine Dateien enthalten.

So beginnen zum Beispiel Pakete mit com.mydomain.mysystem.myutility. Dies würde zu Ordnern src\com, src\com\mydomain, src\com\mydomain\mysystem führen, die keine Dateien enthalten. Höchstwahrscheinlich wird die myutility auch nur nur Ordner enthalten.

Wahrscheinlich wird es auch ein Projektordner sein, dass der Name könnte myutility so der komplette Ordnerpfad myutility\src\main\java\com\mydomain\mysystem\myutility\otherfolder

Diese Praxis ist sehr verbreitet sein enthält, aber es macht uns fragen, wie nützlich es ist. Welchen Vorteil bietet die Situation, in der diese zusätzlichen Ordner nicht erstellt werden? Verwenden Sie zum Beispiel myutility\src\main\java\otherfolder

Es scheint genauso gültig zu sein, aber es spart jedem die zusätzlichen Navigationsschritte. Ich kann Java-Quelldateien mit beiden Methoden problemlos kompilieren.

In einem Projekt befindet sich die Quelle normalerweise in com\mydomain\mysystem. Was bringt es, diese "leeren" Ordner in alle Projekte zu legen?

Nur um klar zu sein, stelle ich nicht die Nützlichkeit der Paketstruktur in Frage. Auch Maven ist klar.

Die Frage ist, warum wir die leeren Ordner verwenden, die im gesamten Repository für eine Organisation identisch sind.

Answer 1

Die Quelldateien (und Klassen) sind so organisiert, dass sie vom Java-Compiler (und der Laufzeitumgebung) gefunden werden können.

Wenn der Java-Compiler Klasse kompiliert, muss sie die Quelle oder Klassendatei jeder Klasse, die Klasse abhängt, so dass es überprüfen kann, dass die Klasse vorhanden ist, dass alle Methoden mit den richtigen Argumenten aufgerufen werden, usw. Wenn es eine Quelldatei, aber keine Klassendatei findet, oder wenn die Klassendatei älter als die Quelldatei ist, kompiliert es die Quelldatei der Klasse, die Sie verwenden.

Der Compiler könnte natürlich nur alle Unterordner Ihres Klassenpfads oder sogar die gesamte Festplatte überprüfen, aber das würde viel Zeit in Anspruch nehmen. Aufgrund dieser Konvention muss der Compiler nur einen einzigen Unterordner für jeden Classpath-Eintrag überprüfen. Natürlich können Sie an verschiedene Lösungen für dieses Problem denken, aber die Leute bei (damals) Sun dachten, dies sei die beste Option.

Natürlich gilt dies auch für die Klassendateien, die zur Laufzeit geladen werden, so dass auch die Klassendateien in einer ähnlichen Ordnerstruktur gespeichert werden.

Beachten Sie auch, dass Java-Anwendungen und -Bibliotheken oft als Jar-Datei gepackt sind (im Prinzip eine Zip-Datei mit der gleichen Ordnerstruktur). In vielen Fällen erscheinen sie daher als einzelne Datei im Dateisystem.

Answer 2

Der Grund dafür ist, Konflikte zu vermeiden und sicherzustellen, dass Klassen eindeutig identifiziert werden können. Das heißt, wenn 2 Klassen den gleichen Namen haben, können sie immer noch über verschiedene Importe geladen werden.

Der sicherste Weg dies zu tun ist durch einen Domain-Namen, die einzigartig ist seiner Natur nach:

com.google.<classname> zum Beispiel.

Ihr Ansatz funktioniert und speichert einige leere Ordner, ist aber nicht skalierbar.