Java Verzeichnistrukturen

[von Spotz]

Hallo!

Einleitung

Ich habe Java über Eclipse zwar schon vor einigen Jahren hin und wieder benutzt, aber eigentlich wusste ich nie so wirklich
bescheid, über Projekte, Namespacing, Verzeichnisstruktur, was ist eine Workbench? Ich war froh, wenn mein Projekt
irgendwie fehlerfrei kompiliert wurde. Von Maven hatte ich schon mal gehört, aber die Lernkurve schien mir zu steil,
da ich ja eigentlich Ruby programmiert habe. In Java habe ich nur hin und wieder Tutorials über Animationen
gemacht, was es in Ruby nicht gibt. Und Beispiel-Implementierungen zu Graphen und Graphalgorithmen und auch noch
ein paar andere kleine Sachen. Diese konnte ich zwar kompilieren und zum Laufen bringen, aber das war mehr, wie
bei Tekken einfach wild auf Knöpfe drücken. Ich wusste nicht wirklich, was die Symbole in Eclipse zu bedeuten haben.

Ich habe nun aber die ersten Schritte in Maven getan und würde gerne genauer bescheid wissen über "die" Java Verzeichnisstruktur,
Projektstruktur, Libraries und Module.

Leider geben die Oracle Docs diesbezüglich (offensichtlich?) nicht sehr viel her, weshalb ich hier nachfrage!

So viel ich aber bisher herausgefunden habe, gibt es scheinbar nicht eine Antwort auf die Frage nach "der Java Verzeichnisstruktur".
Laut den Oracle Docs gibt es nur "IDE Templates" aus verschiedenen Kategorien. Für die Standardkategorie "Standard Java Applications" symbolisiert durch ein Icon einer Tasse Java-Kaffee bieten die Docs

1. Java Application - An empty Java SE project with a main class.
2. Java Class Library - An empty Java class library with no main class.
3. Java Project with Existing Sources - A Java SE project with existing sources.

zur Auswahl an.¹

Es gibt offenbar nur gewisse Primitive und der Rest sind schätze ich Optionen beim Aufruf von der Java VM. Dazwischen ist eigentlich
eine IDE bzw. ein Buildmanager. Es scheint nicht einmal Konventionen einer vorgegebene Verzeichnisstruktur zu geben. Außer für die Benennung von Modulen und den in diesen vorkommenden Projekten sowie der Notwendigkeit von einem Module descriptor 'module-info.java', in der
u.a. Projekte aus dem vorliegenden Modul mit dem escape keyword in ein .jar Archiv exportiert werden und mit dem Projekte, von denen das vorliegende Modul-Projekt (transitiv) abhängig ist mit dem include keyword geladen werden können.

Wobei ich nicht weiss, inwieweit diese Konventionen (fuer Module) nicht auch durch IDE oder Buildmanager vorgegeben sind.

Was Java sicher vorgibt, ist, welche Zeichen dieses und jenes beinhalten darf.

Die Verzeichnisstruktur scheint jedenfalls generell blosse Konvention des jeweiligen Buildmanagers oder der IDE zu sein.
Gut, bei C/Cpp wird eine Verzeichnisstruktur etc. auch erst durch ein Makefile festgelegt.

Trotzdem: Gibt es denn nicht auch Konventionen für ein Verzeichnisse für Vanilla Java (zumindest für die o.g. templates) ?
Vielleicht sogar mit dem Prädikat »best-practice« ?

Ich habe da im Sinn, daß jede Datei den Namen der Klasse in ihr tragen muss, welche main() implementiert. Irgendeine
Regel zu Ordnern gab es auch, aber die fällt mir nicht mehr ein.

Und gibt es umgekehrt z.B. Konventionen für Verzeichnisstrukturen von Buildmanagern für Class Libraries statt für ausführbare Projekte?

Standalone oder nicht

In dem Tutorial über Module unten² ist die Rede davon, ein Modul als standalone Applikation laufen zu lassen oder nicht.
Wann kann ein Projekt, ein Modul, eine Library als standalone Applikation laufen und wann nicht?

Classpath, Root folder & Workbenches?

Ich weiß, wie man die Variable unter Ubuntu setzt, d.h., denke ich. Ich würde sie in ~/.profile setzen.

Aber was ist das, was dort festgelegt wird, eine (von mehreren) "Projekt-root-foldern" ?
Ist das, was der classpath festlegt, eine (von mehreren) "workbenches" ?

Und was wird dort festgelegt? Zum Beispiel das umgebende Verzeichnis, in dem der Benutzer alle Java-Projekte / Klassen /
Library / whatnot Verzeichnisstrukturen plaziert, das aber selbst extern zu diesen ist? Oder etwa der Anfang von
Verzeichnisstrukturen so wie com.mybusiness.... Ich habe gelesen es werden dort auch .jar Archive angehängt bzw.
diese und deren Main-Funktion.

Module
Zu Modulen und Verzeichnisstrukturen bzw. Namenskonventionen finde ich als beste Quelle nur http://tutorials.jenkov.com/java/modules.html², ich weiß aber nicht, in wieweit die dort genannten Konventionen irgendeinem offiziellen Java Standard
entsprechen oder ob dies auch nur wieder irgendwelche Konventionen sind. Aber zumindest der Verzeichnisname
eines Moduls scheint konventional festgelegt zu sein auf Punkte als Trennzeichen und ein '_' scheint verboten zu sein
als reserviertes Zeichen.

Gibt es noch andere feste Konventionen, für Namen von Modul-, Projekt-, oder Library Verzeichnis-Namenssegmente?


Als Standard für die Verzeichnisstruktur wird dort folgende allgemeine Form beschrieben:

com.jenkov.mymodule/com/jenkov/mymodule

Notice the fullstops (.) in the module root directory name. These fullstops need to be there because they are part of the module name! They are not to be interpreted as subdirectory path dividers!

Wobei das Verzeichnis mit den Punkten das Modul symbolisiert und die Sektion mit den Slashes einen Projekt Verzeichnisbaum.

Als root Verzeichnisname wird offenbar

'src/main/java/com'

angegeben (kein Verzeichnisbaum).

From Java 9 a module can be nested under a root directory with the same name as the module.

Jedes Modul in diesem root-Verzeichnis hat dann ein eigenes "module-root" Verzeichnis

src/main/java/com.jenkov.module1

src/main/java/com.jenkov.module2

Das wäre also, wenn ich das richtig verstehe, ein Java-Root + Module-Root

Und mit einem Modul dann Java-Root + Module-Root + Module

src/main/java/com.jenkov.module1/com/jenkov/mymodule

Aber eigentlich komme ich ab hier nicht mehr wirklich mit. ("The directory structure for the above Java package contained in a Java module of the same name, would look like this:")

Das macht für mich keinen Sinn. Dann würden .class oder .java Dateien (? s.o.) also entweder in

src/main/java/com

oder in "package root" oder in "subpackage" gelagert werden?

Java-Root + Module-Root + Module + package root + subpackage

src/main/java/com.jenkov.module1/com/jenkov/mymodule/subpackage

Der Module descriptor würde unter Java-Root + Module-Root positioniert werden?

src/main/java/com.jenkov.module1/module-info.java

Ist der Name "module-info.java" feste Konvention oder kann der Module descriptor auch anders heißen?
Sind die module exports und imports nur einmal anzugeben oder auch auf per-package/per-subpackage basis?



Output folders
Kann ich (auch ohne BuildManager) für eine normale Package- oder auch eine Library Struktur oder aber in einer Modul-Struktur auch den Ausgangsort für z.B. deren "gepackte" Versionen wie .jar-Archive etc. (s.u.) z.B. auf Projektebene festlegen ?

Beziehungsweise:

Kann ich das mit Buildmanager?

Kann man Module und genestete Projektstrukturen oder Libraries kombinieren oder sind Module ein kompletter Ersatz für die traditionelle genestete die traditionelle genestete Projektstruktur?

Libraries
Was ist eine Library im Vergleich zu einem Package? Daß eine library keine main() Funktion implementiert?

Dateiformate
Haben "gepackte" (was ist der richtige Ausdruck?) Module und Bibliotheken andere Dateiformate als .jar-Archive ?
Wenn ja, welche?

Vielen Dank !

Mit besten Grüßen
von Spotz

 

[LimDul]

Hilfreiche Lektüre ist auf jeden Fall der Thread hier: https://www.java-forum.org/thema/classpath-ressourcen-ides-und-build-systeme.194131/

Zum Thema Module halte ich mich mal raus, die nutze ich nicht. Die sind aber eine Ergänzung - kein Ersatz.

Grundsätzlich gilt bei Java: Package Struktur muss äquivalent zur Ordnerstruktur sein. Und Klassenname = Dateiname (bei public classes)

Das heißt, ein Klasse org.javaforum.MyClass muss im Verzeichnis org/javaforum liegen und MyClass.class im kompilierten Zustand bzw. MyClass.java als Source-Datei heißen. Das wird durch Java an sich festgelegt.

Wo genau jetzt der Ordner og/javaforum liegt, in dem die Datei MyClass.class ist, wird durch den Classpath definiert.
Wo genau jetzt der Ordner og/javaforum liegt, in dem die Datei MyClass.java ist, wird beim kompilieren festgelegt.

Grundsätzlich möchte man:
* Source Code und kompilierten Code trennen
* Source Code von Resourcen (wie Bildern, Text-Dateien) trennen, auch wenn im kompilierten Zustand die zusammengefügt werden.

Dafür gibt es in Maven Konventionen, die wie folgt aussehen:

Unterhalb von src/main/java liegen die Java Source-Dateien (Da würde dann der Ordner org/javaforum liegen, und darin MyClass.java)
Unterhalb von src/main/resources liegen Resourcen, die nicht kompiliert werden, sondern einfach mit übernommen werden

Wenn ein Maven-Projekt kompiliert wird, wird das ganze nach target/classes. Das heißt da gibt es dann auch einen Ordner org/javaforum wo dann MyClass.class liegt.

Zusätzlich hat man in einem Projekt meistens noch Testfälle (Unit-Tests). Die möchte man nicht in seiner fertigen Anwendung, die man ggf. ausliefert oder bereitstellt drin haben. Deshalb liegen die in einer separaten Verzeichnisstruktur:
src/test/java Für Source-Code von Test-Dateien
src/test/resource Für Resourcen für Tests.

Beim kompilieren landen die dann unter target/test-classes

Hilft das schon mal was weiter? Ansonsten gerne konkret nachfragen.

 

[von Spotz]

Hallo LimDul,
danke für Deine Antwort.

Um das praktisch etwas zu verdeutlichen, legen wir uns ein Beispielprojekt an. Dazu erstellen wir einen Ordner hallo (für das Projekt) und in diesem einen weiteren Ordner src, in dem wir unsere Quelltexte ablegen. Das können wir über die GUI (z. B. Windows Explorer) erledigen, ich bevorzuge die Befehlszeile, z. B.:

# Windows
md "%USERPROFILE%\Documents\hallo"
md "%USERPROFILE%\Documents\hallo\src"

# Linux
mkdir -p ~/hallo/src

Normalerweise ist ja die Konvention, daß ein Paket mit der URL beginnt. Also 'org'. Hier wird für den classpath, zumindest bei Linux, sofort zwei Segmente erstellt. 'hallo' und 'src'. Wobei ich nicht weiß, ob 'src' ein Segment des Paketes ist oder im Paketnamen nicht vorkommt und nicht nur der Ort für die unkompilierten MyClass.java Dateien ist. Andererseits müsste doch aber jeder Pfad im Paketnamen durch einen Punkt als Subprojekt auftauchen, oder nicht?

Also das erste Hauptproblem ist, daß ich nicht weiß, wo das Javapaket anfängt. Ich denke bei ~/hallo

Meine zweite Frage ist, was bei dem classpath einem "Workspace" bei Eclipse entspricht. Wird dieser überhaupt im classpath angegeben? Ich möchte alle Java-Projekte, Bibliotheken, Module etc. eben in einem oder verschiedenen Workspaces sammeln. Es kann ja aber sein, daß dies gar keine Idee von Java ist, sondern ich dafür einfach beliebige Ordner auswählen kann.

D.h. der classpath würde dann zum Beispiel in einem oder mehreren Nicht-Java Workspace Ordnern jeweils den vollqualifizierten Pfad aus (1) workspace und (2) erstem oder mehreren Segment(en) des Projekt-Ordner etc. speichern? Also, nach gängiger Konvention, meinetwegen

export CLASSPATH=~/workspace1/org.myurl:~/workspace1/org.myurl.project1:~/workspace1/org.myurl.project2

für verschiedene Projekte unter derselben url enthalten und für einen anderen "workspace"

export CLASSPATH=~/workspace2/org.myotherurl:~/workspace2/org.myotherurl.project1:~/workspace2/org.myotherurl.project2

etwa in '~/.profile´
?
Viele Grüße!
von Spotz

 

[von Spotz]

Außerdem:

Was wird als "Projekt-Root Verzeichnis" bezeichnet? Oder was kann bzw. könnte man, falls es denn hilft, als solches bezeichnen?
Das Verzeichnis bereits, das dem ersten Segment in package Schreibweise entspricht? Oder erst dem Unterverzeichnis / Segment, das dem spezifischen Projekt bzw. Paket entspricht?

Vielen Dank!
von Spotz (Mehr als ein elektrischer Rasierer!)

 

[von Spotz]

Ich habe noch einige Fragen vergessen. Das möchte ich gerne schnell nachholen.


Bevor manche der folgenden Fragen aber sinnvoll gestellt werden können, müsste zuerst meine Frage beantwortet sein:

Meine zweite Frage ist, was bei dem classpath einem "Workspace" bei Eclipse entspricht. Wird dieser überhaupt im classpath angegeben? Ich möchte alle Java-Projekte, Bibliotheken, Module etc. eben in einem oder verschiedenen Workspaces sammeln. Es kann ja aber sein, daß dies gar keine Idee von Java ist, sondern ich dafür einfach beliebige Ordner auswählen kann.

Wie startet ihr ein Maven-Projekt

Benutzt ihr einen Generator wie spring initializr für ein boilerplate Maven Projekt? Allerdings ist das doch, wie der Name eben sagt, sehr Spring-Spezifisch. Gibt es auch noch andere Generatoren für Maven-Projekte? Was ist mit Generatoren für Gradle oder Ant Projekte?


Wie wird eine solche von einem Generator erzeugte Archiv-Datei richtig in die IDE importiert?
Soll die IDE den Inhalt in die "Workbench" kopieren, oder entpackt ihr das Archiv in einen Ordner und arbeitet dort damit? Was, wenn ihr diesen Ordner verschieben wollt? Lassen sich die IDEs soetwas mitteilen? Wenn nicht, dann wäre es wohl am sinnigsten, daß "importieren" bedeutet, das Archiv in die "Workbench" entpacken zu lassen.


Kann man in dem Maven-Verzeichnis "src/main/java" Unterpakete, also eine Pakethierarchie erstellen?

Unterhalb von src/main/java liegen die Java Source-Dateien (Da würde dann der Ordner org/javaforum liegen, und darin MyClass.java)

Die docs (https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) geben darüber keine Auskunft.


Kann man Module und Pakete bzw. Bibliotheken kombinieren und macht das Sinn?

Die Frage ist, wie der Autor der diesbezüglichen Antwort selber ja feststellt, weiter unbeantwortet. Wobei die Antwort zumindest nahelegt, daß die Kombination von Modulen und Paketen / anderes möglich ist.

Zum Thema Module halte ich mich mal raus, die nutze ich nicht. Die sind aber eine Ergänzung - kein Ersatz.

Vielen Dank!

von Spotz

 

[temi]

Kann man in dem Maven-Verzeichnis "src/main/java" Unterpakete, also eine Pakethierarchie erstellen?

Wenn du mit "Unterpaketen" Packages meinst. Ja. Da gehören die hin.

Es gibt i. d. R. noch den Pfad "src/test/java" in dem die dazugehörigen Unittests in einer identischen Struktur liegen.

Beispiel du hast folgende Packages:

package de.example.myproject
package de.example.myproject.core
package de.example.myproject.util

Dann liegen die entsprechenden Dateien unter:

src/main/java/de/example/myproject
src/main/java/de/example/myproject/core
src/main/java/de/example/myproject/util

Desgleichen unter src/test/java/... nur halt für die zugehörigen Testklassen.

Wie startet ihr ein Maven-Projekt

Ich nutze Gradle, aber das sollte keinen Unterschied machen und ganz simple "Neues Projekt - Gradle ..." in der IDE (IntelliJ IDEAS). Damit wird die korrekte Struktur automatisch erzeugt. Das wird in Eclipse sicher genauso funktionieren.

 

[von Spotz]

Hallo,
ich hoffe es ist nicht zu früh, um noch einmal zu fragen. Also ich meine, wenn ich jeden Tag zwei Mal frage geht es auch nicht schneller. Alternativ könnte man sagen: Ich will nicht spammen.

Ich wäre nur gerne in der Lage, selber Projekte zu erzeugen ohne Notwendigkeit für Tutorials zur Erzeugung des Projektes, sodaß ich selber ein wenig mit Microservices

Ich hoffe daher, es ist ok, wenn ich noch einmal die wichtigsten Fragen stelle

Eine weitere wurde ja freundlicherweise im letzten Post schon von temi beantwortet !
Allerdings hätte ich eine Frage dazu:
Ist

Also die ersten beiden noch unbeantworteten Fragen stammen aus dem Post

https://www.java-forum.org/thema/java-verzeichnistrukturen.195739/#post-1290243

welche die folgenden sind:

1. Wie startet ihr ein Maven-Projekt
2. Wie wird eine solche von einem Generator erzeugte Archiv-Datei richtig in die IDE importiert?
3. Kann man Module und Pakete bzw. Bibliotheken kombinieren und macht das Sinn?

Und aus diesem Post (https://www.java-forum.org/thema/java-verzeichnistrukturen.195739/#post-1290091)

4, Es gibt den Begriff "project root." Entspricht der Umfang dieses Begriffes dem, was man durch den "classpath" setzt?
5. Wenn man den classpath zu einem Projekt setzen möchte, wo fängt das Projekt (Paket) an...?
... wenn sich a) so verhält, wie LimDui es oben ausdrückt:

Grundsätzlich gilt bei Java: Package Struktur muss äquivalent zur Ordnerstruktur sein. Und Klassenname = Dateiname (bei public classes)

weiters b) so verhält, daß man als Segmente für die Paketnotation eine URL wählt und c) so, daß man mehrere Projekte hat, die etwa mit

org.mycompany

anfangen, also:

org.mycompany.package1
org.mycompany.package2
org.mycompany.library1

Wahrscheinlich bei dem tiefsten (letzten) Segment, oder? Oder etwa genau umgekehrt, bei dem Segment 'org' in diesem Beispiel - weil darunter eben viele Projekte zusammengefaßt sind, die wahrscheinlich irgendwie zusammengehören. Aber gerade das ist ja nicht zwingend nötig. Eine 'org.mycompany' kann ja an ganz verschiedenen Projekten arbeiten. Deshalb erscheint mir die erste Konjektur vom spezifischsten Segment am wahrscheinlichsten.

6. Außerdem gibt es bei Eclipse den Begriff des "Workspace". Ist dies ein Javabegriff? Ist dies eine Eclipse-spezifische Sache? Kann ich auch ohne Eclipse mehrere Workspaces für verschiedene Sorten von Projekten führen? Wie spielt das mit dem classpath zusammen?

7. Kann man in dem Maven-Verzeichnis "src/main/java" Unterpakete, also eine Pakethierarchie erstellen?
Ist Beantwortet. Siehe oben. Danke temi!

8. Wie sieht die komplette Verzeichnisstruktur von Modul + Projekt aus?
Siehe die den Eröffnungsthread bezüglich der Frage, wie dann (wenn die Kombination von Modul und etwa Package oder Library Sinn macht) die korrekte komplette Verzeichnisstruktur aussieht. (und wie man auf das Modul und die Unterprojekte zugreifen würde? classpath? Dann ähnliche Frage wie oben.)
Diese wäre mir besonders wichtig.

Außerdem:

Korrellar zur Frage 7:
9. Wie regelt Maven über den classpath diese Einteilung in die Verzeichnisse 'src/main/java', 'src/main/resources' etc.

bzw.

10. Wie wird im classpath zwischen den Verzeichnissen mit Java-Dateien, Verzeichnissen mit kompilierten .class Dateien, mit .jar Dateien und anderen unterschieden?

11. Ähnlich zu obiger Frage: Wie lege ich in Java (über den classpath? über die options für javac?) die Output folders für .jar Archive fest?

Ja das ist viel, aber ich wollte das gerne einmal die meisten Fragen stellen, die mir einfallen, anstatt eben Salamitaktik-mäßig alles einzeln zu erfragen. Ich hoffe, die Fragen geben sich so gegenseitig einen gewissen Kontext.

Ich möchte gerne endlich mit eigenen Java Projekten starten und selber mit Microservices experimentieren. Das geht nur, wenn ich Antworten auf die obigen Fragen habe.

Im Gegensatz zu Java's classpath & co ist es nämlich sehr gut dokumentiert, wie man makefiles für C++ schreibt, es gibt viele Beispiele und es war mir selbst als Anfänger möglich, ein (für einen Anfänger) relativ gutes und zumindest ausreichendes Makefile zu schreiben und damit ein C++ Projekt zu kompilieren.

Vielen Dank und frohes neues Jahr!
vonSpotz

 

[kneitzel]

Wie startet ihr ein Maven-Projekt

Einfach eine POM.xml erstellen oder erstellen lassen. Nichts anderes macht Spring Initializr. Die IDEs haben oft genug eigene Möglichkeiten incl. Auswahl eines Archetyps.

Ich selbst verzichte sehr gerne und kopiere mir die pom.xml direkt so zusammen, wie ich diese brauche. Das geht deutlich schneller und die POM ist auch direkt schön aufgebaut mit veränderlichen Informationen in den Properties und so.

Wie wird eine solche von einem Generator erzeugte Archiv-Datei richtig in die IDE importiert?

Du Entpackst das generierte Archiv und dann öffnest Du in der Regel einfach das Verzeichnis mit der pom.xml. IntelliJ erkennt das Maven Projekt und Eclipse ebenso. Netbeans nutze ich nicht.
Generell ist die IDE aber nur als Add On zu sehen - das Maven projekt an sich ist ausreichend - so habe ich bei allen meinen Projekten auch den Maven Wrapper im Einsatz.

Das Verschieben ist in der Regel absolut kein Problem. In IntelliJ einfach Projekt schließen, Verzeichnis verschieben und dann an neuer Stelle öffnen. Eclipse hat das nicht so, da hier die Idee der Workbench existiert. Das ändert aber auch nicht wirklich wesentlich etwas. Prinzipiell ist es z.B. möglich, die Projekte an beliebigen Stellen zu haben und in der Workbench nur zu verlinken.

Kann man in dem Maven-Verzeichnis "src/main/java" Unterpakete, also eine Pakethierarchie erstellen?

Selbstverständlich. Das hat ja auch nichts mehr mit Maven zu tun sondern mit Java. Maven nutzt das Verzeichnis ja als Source Verzeichnis. Was da dann drin liegt ist dann etwas, das Java auswertet. Alles, was Maven macht, ist ja der Aufruf von javac.

Die docs (https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) geben darüber keine Auskunft.

Mit der Erläuterung, dass dies Java spezifisch ist, dürfte das auch klar sein.

Kann man Module und Pakete bzw. Bibliotheken kombinieren und macht das Sinn?

Da ist die Frage, was Du überhaupt genau meinst. Wenn Du ein Modul hast, dann brauchst Du auch Pakete. In der module-info gibst Du ja an, welche Pakete Du exportierst und so.
Da evtl. einfach einmal mit den Details des Modulsystems beschäftigen - ein möglicher Startpunkt wäre z.B.

Java 9: Das neue Modulsystem Jigsaw - Tutorial

Jigsaw in Java 9: Einführung in die Grundlagen, fortgeschrittene Techniken und Migration (mit Beispielen)

www.informatik-aktuell.de

Die Frage ist, wie der Autor der diesbezüglichen Antwort selber ja feststellt, weiter unbeantwortet. Wobei die Antwort zumindest nahelegt, daß die Kombination von Modulen und Paketen / anderes möglich ist.

Auf was genau beziehst Du Dich? Der Maven Link zur Verzeichnisstruktur geht auf Module und Packages nicht ein, denn das sind Java Spezifische Dinge und haben mit Maven (dem Buildtool) nichts zu tun.

 

[von Spotz]

Hallo Kneitzel,

vielen Dank für Deine Antwort.

Kann man Module und Pakete bzw. Bibliotheken kombinieren und macht das Sinn?

Da ist die Frage, was Du überhaupt genau meinst. Wenn Du ein Modul hast, dann brauchst Du auch Pakete. In der module-info gibst Du ja an, welche Pakete Du exportierst und so.
Da evtl. einfach einmal mit den Details des Modulsystems beschäftigen - ein möglicher Startpunkt wäre z.B.

Java 9: Das neue Modulsystem Jigsaw - Tutorial

Jigsaw in Java 9: Einführung in die Grundlagen, fortgeschrittene Techniken und Migration (mit Beispielen)

www.informatik-aktuell.de

Vielen Dank für den Link. Zu dem Module Descriptor findet man aber ehrlich gesagt sehr schnell etwas. Wozu man praktisch nichts findet, das ist die Verzeichnisstruktur von Modulen + Projekt

In Frage 8 hatte ich gefragt:

8. Wie sieht die komplette Verzeichnisstruktur von Modul + Projekt aus?
Siehe die den Eröffnungsthread bezüglich der Frage, wie dann (wenn die Kombination von Modul und etwa Package oder Library Sinn macht) die korrekte komplette Verzeichnisstruktur aussieht. (und wie man auf das Modul und die Unterprojekte zugreifen würde? classpath? Dann ähnliche Frage wie oben.)
Diese wäre mir besonders wichtig.

Ich zitiere auch nochmal aus dem Eröffnungsthread:

From Java 9 a module can be nested under a root directory with the same name as the module.

Jedes Modul in diesem root-Verzeichnis hat dann ein eigenes "module-root" Verzeichnis

src/main/java/com.jenkov.module1

src/main/java/com.jenkov.module2

Das wäre also, wenn ich das richtig verstehe, ein Java-Root + Module-Root

Und mit einem Modul dann Java-Root + Module-Root + Module

src/main/java/com.jenkov.module1/com/jenkov/mymodule

Aber eigentlich komme ich ab hier nicht mehr wirklich mit. ("The directory structure for the above Java package contained in a Java module of the same name, would look like this:")

Das macht für mich keinen Sinn. Dann würden .class oder .java Dateien (? s.o.) also entweder in

src/main/java/com

oder in "package root" oder in "subpackage" gelagert werden?

Java-Root + Module-Root + Module + package root + subpackage

src/main/java/com.jenkov.module1/com/jenkov/mymodule/subpackage

Der Module descriptor würde unter Java-Root + Module-Root positioniert werden?

src/main/java/com.jenkov.module1/module-info.java

Könntest Du mir das freundlicherweise beantworten?

Alles Gute!
von Spotz ("der neue IoT Feuermelder, der selber über Ihr Smartphone Feuer legt, um diese schneller melden zu können")

 

[kneitzel]

Also ich habe ehrlich gesagt Probleme, Dich wirklich zu verstehen, da Du Zitate zu bringen scheinst ohne die genaue Quelle zu nennen. Zumindest finde ich Deine Zitate nicht und daher kann ich Dir auch nicht erläutern, was da ein Autor irgendwo irgendwie geschrieben hat und was er genau gemeint hat.

Generell Du hast ein Projekt Root - das ist einfach der Ordner, in dem das Projekt sich befindet. Das ist unabhängig von Sprache, Buildtool, ...
Dann hast Du Source / Ressource Root Directories. Das sind Ordner, in denen sich irgendwas befindet. Was genau ist dabei nicht spezifiziert.
Je nach Build Tool (z.B. Maven) kann man diese Root Verzeichnisse festlegen. Bei Maven ist der Default eben src/main/java src/test/java für Java Sourcen (einmal für das Projekt selbst und das Andere ist für den Test) und src/main/resource src/test/resource für Ressourcen.
Dies sind aber Einstellungen, die beliebig gewählt werden können. Und die Angaben sind relativ zu dem Project Root Ordner - was bei Maven der Ordner ist, in dem die pom.xml liegt.

Maven kennt dann Sub-Projekte, welche Module genannt werden. Das sind dann Maven Module. Dies ist nicht zu verwechseln mit Java Modulen.
Wenn Du ein Macen Modul hast, dann hast Du in der pom.xml etwas wie:

    <modules>
        <module>ModulName</module>
    </modules>

Dann schaut er in dem Verzeichnis ModulName nach einer pom.xml und verarbeitet dieses Maven Projekt ebenfalls.
Dadurch hast Du dann ggf. eine Verzeichnisstruktur wie:
<Projekt Root>/
- pom.xml
- <ModulName>/
- - pom.xml

==> Reine Maven Projekte - hier war noch nichts mit Java oder so!

Wenn Du ein Projekt in Java (9+) übersetzt, ist dies ein Modul. Wenn Du keine module-info.java hast, dann hast Du ein unnamed module. Das hat dann ein requires auf alles, was im Classpath ist und ein exports auf alle Namespaces.
Wo die Source Dateien liegen, ist Java egal. Der Java Compiler muss nur eben richtig aufgerufen werden. Der java Compiler will einfach wissen, was das Basis Verzeichnis ist. Und ab da werden die Klassen gelesen und die Unterverzeichnisse werden zu Teilen des Namespaces. Modulname kommt aus der module-info.java (oder als Argument übergeben, aber module-info.java ist der übliche Weg!)
Das ist etwas, mit dem Du auch spielen kannst. Du kannst also Code von Hand übersetzen. Wenn Du keine Source und Target Verzeichnisse angibst, so ist dies das aktuelle Verzeichnis.

Wenn Du ein Buildtool verwen dest, dann nimmt dieses Tool natürlich die eigene Konfiguration um darauf basierend Aufrufe zu tätigen. Dazu gehören dann auch Java Aufrufe. Wenn Dich die Aufrufe von Maven interessieren, dann kannst Du beim Aufruf die -X Option mit angeben. Dann sieht das z.B. so aus:
[CODE highlight="113"][INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ mavenproject1 ---
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=439300, ConflictMarker.markTime=229700, ConflictMarker.nodeCount=118, ConflictIdSorter.graphTime=168300, ConflictIdSorter.topsortTime=79700, ConflictIdSorter.conflictIdCount=45, ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=2310700, ConflictResolver.conflictItemCount=72, DefaultDependencyCollector.collectTime=375577800, DefaultDependencyCollector.transformTime=3262000}
[DEBUG] org.apache.maven.plugins:maven-compiler-plugin:jar:3.8.1
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.codehaus.plexuslexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-core:jar:3.0:compile
[DEBUG] org.apache.maven:maven-settings:jar:3.0:compile
[DEBUG] org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG] org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG] org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG] org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG] org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG] org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG] org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG] org.codehaus.plexuslexus-interpolation:jar:1.14:compile
[DEBUG] org.codehaus.plexuslexus-classworlds:jar:2.2.3:compile
[DEBUG] org.codehaus.plexuslexus-component-annotations:jar:1.7.1:compile (version managed from default)
[DEBUG] org.sonatype.plexuslexus-sec-dispatcher:jar:1.3:compile
[DEBUG] org.sonatype.plexuslexus-cipher:jar:1.4:compile
[DEBUG] org.apache.maven.shared:maven-shared-utils:jar:3.2.1:compile
[DEBUG] commons-io:commons-io:jar:2.5:compile
[DEBUG] org.apache.maven.shared:maven-shared-incremental:jar:1.1:compile
[DEBUG] org.codehaus.plexuslexus-java:jar:0.9.10:compile
[DEBUG] org.ow2.asm:asm:jar:6.2:compile
[DEBUG] com.thoughtworks.qdox:qdox:jar:2.0-M9:compile (version managed from default)
[DEBUG] org.codehaus.plexuslexus-compiler-api:jar:2.8.4:compile
[DEBUG] org.codehaus.plexuslexus-compiler-manager:jar:2.8.4:compile
[DEBUG] org.codehaus.plexuslexus-compiler-javac:jar:2.8.4:runtime
[DEBUG] Created new class realm plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
[DEBUG] Importing foreign packages into class realm plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
[DEBUG] Imported: < maven.api
[DEBUG] Populating class realm plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
[DEBUG] Included: org.apache.maven.plugins:maven-compiler-plugin:jar:3.8.1
[DEBUG] Included: org.sonatype.sisu:sisu-inject-bean:jar:1.4.2
[DEBUG] Included: org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7
[DEBUG] Included: org.codehaus.plexuslexus-utils:jar:2.0.4
[DEBUG] Included: org.sonatype.aether:aether-util:jar:1.7
[DEBUG] Included: org.codehaus.plexuslexus-interpolation:jar:1.14
[DEBUG] Included: org.codehaus.plexuslexus-component-annotations:jar:1.7.1
[DEBUG] Included: org.sonatype.plexuslexus-sec-dispatcher:jar:1.3
[DEBUG] Included: org.sonatype.plexuslexus-cipher:jar:1.4
[DEBUG] Included: org.apache.maven.shared:maven-shared-utils:jar:3.2.1
[DEBUG] Included: commons-io:commons-io:jar:2.5
[DEBUG] Included: org.apache.maven.shared:maven-shared-incremental:jar:1.1
[DEBUG] Included: org.codehaus.plexuslexus-java:jar:0.9.10
[DEBUG] Included: org.ow2.asm:asm:jar:6.2
[DEBUG] Included: com.thoughtworks.qdox:qdox:jar:2.0-M9
[DEBUG] Included: org.codehaus.plexuslexus-compiler-api:jar:2.8.4
[DEBUG] Included: org.codehaus.plexuslexus-compiler-manager:jar:2.8.4
[DEBUG] Included: org.codehaus.plexuslexus-compiler-javac:jar:2.8.4
[DEBUG] Configuring mojo org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile from plugin realm ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1, parent: java.net.URLClassLoader@621be5d1]
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile' with basic configurator -->
[DEBUG] (f) basedir = C:\Projects\temp
[DEBUG] (f) buildDirectory = C:\Projects\temp\target
[DEBUG] (f) compilePath = [C:\Projects\temp\target\classes, C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13.jar, C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13-win.jar, C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13.jar, C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13-win.jar, C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13.jar, C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13-win.jar]
[DEBUG] (f) compileSourceRoots = [C:\Projects\temp\src\main\java]
[DEBUG] (f) compilerId = javac
[DEBUG] (f) debug = true
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) failOnError = true
[DEBUG] (f) failOnWarning = false
[DEBUG] (f) forceJavacCompilerUse = false
[DEBUG] (f) fork = false
[DEBUG] (f) generatedSourcesDirectory = C:\Projects\temp\target\generated-sources\annotations
[DEBUG] (f) mojoExecution = org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile {execution: default-compile}
[DEBUG] (f) optimize = false
[DEBUG] (f) outputDirectory = C:\Projects\temp\target\classes
[DEBUG] (f) parameters = false
[DEBUG] (f) project = MavenProject: com.mycompany:mavenproject1:1.0-SNAPSHOT @ C:\Projects\temp\pom.xml
[DEBUG] (f) projectArtifact = com.mycompany:mavenproject1:jar:1.0-SNAPSHOT
[DEBUG] (s) release = 11
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@47e4d9d0
[DEBUG] (f) showDeprecation = false
[DEBUG] (f) showWarnings = false
[DEBUG] (f) skipMultiThreadWarning = false
[DEBUG] (f) source = 11
[DEBUG] (f) staleMillis = 0
[DEBUG] (s) target = 11
[DEBUG] (f) useIncrementalCompilation = true
[DEBUG] (f) verbose = false
[DEBUG] -- end configuration --
[DEBUG] Using compiler 'javac'.
[DEBUG] Adding C:\Projects\temp\target\generated-sources\annotations to compile source roots:
C:\Projects\temp\src\main\java
[DEBUG] New compile source roots:
C:\Projects\temp\src\main\java
C:\Projects\temp\target\generated-sources\annotations
[DEBUG] CompilerReuseStrategy: reuseCreated
[DEBUG] useIncrementalCompilation enabled
[DEBUG] Stale source detected: C:\Projects\temp\src\main\java\module-info.java
[DEBUG] Stale source detected: C:\Projects\temp\src\main\java\com\mycompany\mavenproject1\SystemInfo.java
[DEBUG] Stale source detected: C:\Projects\temp\src\main\java\com\mycompany\mavenproject1\App.java
[INFO] Changes detected - recompiling the module!
[DEBUG] Classpath:
[DEBUG] C:\Projects\temp\target\classes
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13.jar
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13.jar
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13.jar
[DEBUG] Modulepath:
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13-win.jar
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13-win.jar
[DEBUG] C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13-win.jar
[DEBUG] Source roots:
[DEBUG] C:\Projects\temp\src\main\java
[DEBUG] C:\Projects\temp\target\generated-sources\annotations
[DEBUG] Command line options:
[DEBUG] -d C:\Projects\temp\target\classes -classpath C:\Projects\temp\target\classes;C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13.jar;C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13.jar;C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13.jar; --module-path C:\Users\A419779\.m2\repository\org\openjfx\javafx-controls\13\javafx-controls-13-win.jar;C:\Users\A419779\.m2\repository\org\openjfx\javafx-graphics\13\javafx-graphics-13-win.jar;C:\Users\A419779\.m2\repository\org\openjfx\javafx-base\13\javafx-base-13-win.jar; -sourcepath C:\Projects\temp\src\main\java;C:\Projects\temp\target\generated-sources\annotations; -s C:\Projects\temp\target\generated-sources\annotations -g -nowarn --release 11 -encoding UTF-8 --module-version 1.0-SNAPSHOT
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 3 source files to C:\Projects\temp\target\classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.306 s
[INFO] Finished at: 2022-01-03T14:49:08+01:00
[INFO] ------------------------------------------------------------------------[/CODE]
(Zeile 113 zeigt die Option des Aufrufs an!)

 

[von Spotz]

PS: Ich möchte es an der Stelle gerne noch einmal sagen. Ich bin nicht zu faul zum Suchen. Ich bin leider momentan einfach krankheitsmäßig etwas eingeschränkt. Ich bitte um Verständnis, wenn ich das nicht genauer ausführen möchte. Ich hoffe ihr merkt, daß ich so gut ich kann versuche mir Gedanken zu machen und diese so korrekt wie es mir als Anfänger möglich ist zu formulieren. Ich möchte niemandem die Zeit stehlen. Was ich sagen kann ist, daß es mir sehr helfen würde, eine Beschäftigung zu haben und nach dem Lesen meines Microservice Buches mich dann auch tatsächlich selber damit beschäftigen und herumexperimentieren zu können. Weshalb ich eben eure Nachsicht sehr zu schätzen wüsste.
Vielen Dank nochmal,
von Spotz

 

[von Spotz]

Also ich habe ehrlich gesagt Probleme, Dich wirklich zu verstehen, da Du Zitate zu bringen scheinst ohne die genaue Quelle zu nennen. Zumindest finde ich Deine Zitate nicht und daher kann ich Dir auch nicht erläutern, was da ein Autor irgendwo irgendwie geschrieben hat und was er genau gemeint hat.

Ich habe mich verschrieben. Es sollte "Eröffnungspost" heißen und nicht "Eröffnungsthread". Eröffnungspost natürlich von diesem Thread und Autor damit: ich.

Und bitte nochmal: Das hat nichts mit Maven zu tun. Und auch über den module descriptor muss ich noch nichts wissen, solange ich nicht weiß, wie (Konvention für Pfad bzw. Verzeichnisstruktur von einem Modul und für die Projekte unter einem Modul) der Pfad zu dem Modul bzw. der komplette Pfad zu einem Projekt des Moduls und auch der module-descriptor im classpath unterzubringen ist.

Viele Grüße!
von Spotz

 

[kneitzel]

Ich habe mich verschrieben. Es sollte "Eröffnungspost" heißen und nicht "Eröffnungsthread". Eröffnungspost natürlich von diesem Thread und Autor damit: ich.

Das war mir klar - aber Du hast da viele Zitate gebracht und ich sehe die Quelle schlicht nicht.

Und bitte nochmal: Das hat nichts mit Maven zu tun. Und auch über den module descriptor muss ich noch nichts wissen, solange ich nicht weiß, wie (Konvention für Pfad bzw. Verzeichnisstruktur von einem Modul und für die Projekte unter einem Modul) der Pfad zu dem Modul bzw. der komplette Pfad zu einem Projekt des Moduls und auch der module-descriptor im classpath unterzubringen ist.

Weil das Quatsch ist, was Du da schreibst!

Hast Du versucht die Beschreibung, die ich zusammen geschrieben habe, zu verstehen? Diese Arbeit habe ich mir nicht gemacht, weil ich einfach Langeweile hatte sondern um damit ein Grundverständnis zu schaffen.

a) Von was für Modulen schreibst Du? Maven Module? Java Module? Irgend welche anderen Module?
b) von was für Projekten schreibst Du? Maven projekte? allgemein irgendwelche Projekte? Hat dein Code irgendwelche Project Klassen?

Ein Java Modul ist eine Sammlung von Klassen die in der Regel eine Modul-Beschreibung haben. Da hast Du keine Projekte drin (Ok, Project Klassen kannst Du da natürlich ganz viele drin haben). Mit einem Projekt (oder einem Sub-Projekt, in Maven "Modul" genannt, s.o.) kannst Du sowas erzeugen. Du kannst sowas aber auch Manuell erzeugen. Und Du kannst verschienden jar Dateien die gleiche Modulbezeichnung geben.
Da dies aber so natürlich schnell zu Verwirrung führen kann, sollte man das dann im Namen kenntlich machen. Aber damit haben wie die Java Ebene wieder verlassen.
Wir können uns dies aber dann bei Maven ansehen, denn da findet man dann wieder eine Benennungs-Grundlage:
org/openjfx/javafx-graphics/17.0.1/javafx-graphics-17.0.1.jar
org/openjfx/javafx-base/17.0.1/javafx-base-17.0.1-win.jar

Es gibt dann also (im Maven Repository) eine Verzeichnisstruktur die aus groupId, artifactId und Version aufgebaut ist und in der Datei hat man groupId, Version und ggf. Plattform.

Aber das ist wieder eine reine Maven Geschichte. Java interessiert sich nicht für den Namen!

 

[temi]

Ich habe mich verschrieben. Es sollte "Eröffnungspost" heißen und nicht "Eröffnungsthread". Eröffnungspost natürlich von diesem Thread und Autor damit: ich.

Und bitte nochmal: Das hat nichts mit Maven zu tun. Und auch über den module descriptor muss ich noch nichts wissen, solange ich nicht weiß, wie (Konvention für Pfad bzw. Verzeichnisstruktur von einem Modul und für die Projekte unter einem Modul) der Pfad zu dem Modul bzw. der komplette Pfad zu einem Projekt des Moduls und auch der module-descriptor im classpath unterzubringen ist.

Viele Grüße!
von Spotz

Warum startest du nicht einfach mal die IDE deines Vertrauens und erstellst ein neues Maven Projekt?

Da wird die Struktur komplett angelegt und du kannst loslegen mit dem Programmieren.

Ich weiß jetzt nicht welche Erfahrungen du bereits im Programmieren hast, aber ich halte es für sinnvoll einfach mal mit einem simplen Projekt zu starten. Von mir aus auch etwas mit Zugriff auf eine DB, die du zunächst einfach manuell in einem Container laufen lässt (das sollte mit ein paar Zeilen auf der Konsole erledigt sein). Das kannst du dann später erweitern, indem du diesen Container durch Maven starten lässt. Und wenn das läuft, dann kannst du ein Multiprojekt aus vielen Einzelprojekten beginnen.

 

[temi]

Warum startest du nicht einfach mal die IDE deines Vertrauens und erstellst ein neues Maven Projekt?

Alternativ kannst du auch mit Maven ein neues Projekt starten und dann mit der IDE deines Vertrauens öffnen. Damit hast du dann auch gleich zwei deiner Fragen selbst beantwortet.

https://maven.apache.org/guides/getting-started/index.html#how-do-i-make-my-first-maven-project

 

[von Spotz]

Lieber Kneitzel,ich möchte gerne den classpath verstehen und wie man dort ich sage mal grob "die richtigen Angaben macht wenn man x oder y will". Ich möchte erst noch gar nicht in BuildManager-Materie eintauchen. Ich danke Dir wirklich für Deine Ausführungen zu Maven und Modulen und zu dem Inhalt des module descriptors. Was mich aber interessiert ist genau das, was Du so beschreibst:

Wo die Source Dateien liegen, ist Java egal. Der Java Compiler muss nur eben richtig aufgerufen werden. Der java Compiler will einfach wissen, was das Basis Verzeichnis ist. Und ab da werden die Klassen gelesen und die Unterverzeichnisse werden zu Teilen des Namespaces. Modulname kommt aus der module-info.java (oder als Argument übergeben, aber module-info.java ist der übliche Weg!)
Das ist etwas, mit dem Du auch spielen kannst

Und damit das für mich nicht mehr wie "Der Strom kommt aus der Steckdose" klingt, würde ich gerne genau wissen "wie und was". Wie teile ich Java mit, wo meine source Dateien liegen, wo meine .class Dateien liegen, andere Module, target, test. Wo beginnt im classpath die Angabe einer project-root-folder bzw. wo hört sie auf, etc. Ich möchte es erstmal gerne manuell/analog lernen, damit ich weiss, was die IDE da überhaupt anstellt.

Beziehungsweise den classpath Anteil daran.
Ich weiß, daß die andere Hälfte davon an den Optionen liegt, die ich javac übergebe. Was aber auch nicht unabhängig davon ist, was ich vorher in den classpath geschrieben habe.

Beziehungsweise in "Frage 8" konkret die Anatomie einer Modul + Projekt Verzeichnisstruktur mit Namenskonventionen z.B. für die Modulnamen

Nochmal alles Gute!

 

[temi]

Wie teile ich Java mit, wo meine source Dateien liegen

Darauf wurde schon in der ersten Antwort verwiesen: https://www.java-forum.org/thema/classpath-ressourcen-ides-und-build-systeme.194131/

Beim Aufruf von "javac" oder "java" teilst du java mit, wo deine Dateien liegen. Meist machst du das halt nicht von Hand, sondern die IDE oder das Buildsystem erledigen das für dich.

 

[kneitzel]

,ich möchte gerne den classpath verstehen

Ok, das ist ein wichtiger Punkt, aber dir ist klar, dass dieser Punkt in den bisherigen Ausführungen nicht aufgetaucht ist?

Wenn der Java Compiler etwas übersetzen soll oder ein Java Programm ausgeführt werden soll, dann müssen alle benötigten Klassen und Ressourcen vorhanden sein, zugreifbar sein. Der Classpath gibt an, wo nach Klassen / Ressourcen gesucht werden soll.

Dies kann man manuell machen und bei java / javac Aufrufen angeben. Teilweise kann dies auch hinterlegt werden (z.B. Manifest Datei eines jar Files).

Da das manuelle Angeben umständlich ist, wird diese Arbeit abgetreten:
- Der Java Compiler wird vom Projektmanagement aufgerufen. Die Projektverwaltung ist also hier dann verantwortlich. Dazu gehören dann Dinge wie: wo liegen die Sourcen, welche Abhängigkeiten gibt es, u.s.w.
- Bei der Ausführung hat man dann alles hinterlegt, also z.B. durch ein "Fat JAR" -> alles ist enthalten oder eben durch Angabe eines Manifests, das dann einen classpath vorgibt.

Das wäre eine einfache Übersicht zum Classpath.

Wie teile ich Java mit,

Hier kann man einfach javac -help und java -help aufrufen. Dann sieht man viele Parameter, die man nutzen kann.
Damit kann man sich erarbeiten, was diese Komponenten können.

Aber brauchst Du das? Du arbeitest später mit einem Projekt-Management. Egal ob Maven oder das von einer IDE.
Das ist wie beim Auto fahren: Musst Du alle Details eines Motors verstehen? Alle Parameter, die der Steuercomputer an den Motor geben kann?

Beziehungsweise in "Frage 8" konkret die Anatomie einer Modul + Projekt Verzeichnisstruktur mit Namenskonventionen

Da gibt es keine feste Struktur. Du kannst alles an beliebige Orte legen. Daher snd ja die Parameter da.

Es gibt Standards - javac nimmt das aktuelle Verzeichnis um nach den java Dateien zu schauen und legt die class Dateien entsprechend ab. Macht ggf. so aber wenig Sinn.

Es gibt dann bei diversen Projekt-Management Systemen auch Vorschläge bzw. wenn ein neues Projekt erstellt wird, wird etwas vorgegeben. Die sind aber willkürlich. Ob erzeugte Dinge nun in out, target oder sonst wo landen: Es ist egal. Da hat also jemand, der da ein Tooling erstellt hat, einfach etwas gewählt, dass er für sinnvoll hielt.
Aber das muss Dir nicht gefallen! Du willst es anders haben? Dann änderst Du es einfach. Du kannst das meistens immer einstellen. (Also Eclipse, Intellij, maven, ant, gradle, ..... da ist das alles frei konfigurierbar!)

Hier ist wichtig: Es gibt hier keine fest vorgegebene Struktur! Aber wenn man sich auf ein Tool festlegt, dann macht es Sinn, sich da an die "Standards" zu halten. Das liegt einfach nur daran, dass es eben dieses "was erwarte ich" wiedergibt. Bei einem Maven Projekt: Was erwarte ich? Java Sourcen unter src/main/java. Wenn Du aber nun etwas generierst, dann bekommst Du ggf. etwas erzeugt, wo es unter src liegt. Das ist dann verwirrend (und liegt daran, dass da jemand z.B. aus einem eclipse Projekt ein Maven Projekt generiert hat... etwas, das ich nicht gut finde!).
Das ist dann etwas, dass man oft als Convention over Configuration bezeichnet.

Die Frage 8 macht also in Hinsicht auf Java keinen Sinn. Java hat da keine Verzeichnisstruktur. Maven hat da auch keine fest vorgegebene Struktur aber es macht durchaus Sinn, die Standard Einstellungen zu nehmen. Man muss also aufpassen, dass man hier die Ebenen nicht durcheinander wirft. Daher hatte ich in #10 versucht, das etwas zu erläutern.

 

[von Spotz]

Hallo,
Hallo Kneitzel,

würdet ihr mir bitte eine Antwort auf die Frage geben, wie ich über die Kommandozeile eine Library kompiliere? Was macht überhaupt eine Library aus? Was unterscheidet sie von einem Modul? Eine Java Datei eines Moduls oder eines Unterpaket eines Moduls das ich mit javac zu einer .class Datei kompiliert habe kann ich doch mit "jar" auch zu einem (ausführbaren standalone) .jar Archiv packen? Gibt es da am Ende gar keinen Unterschied? Vielleicht, ob die .jar Datei ausführbar ist (wegen einer Klasse, die eine main() Funktion implementiert, oder nicht) ?

Ich wäre sehr dankbar für ein Unix Kommandozeilen Beispiel. Ich habe leider nichts Konkretes über Libraries gefunden. Nur a) wie man eben ab Java 9 Module kompiliert und b) wie man mit jar ein .jar Archiv erstellt. Dann gibt es ja noch den linker. Spielt der eine Rolle?

Vielen Dank!
Euer von Spotz

 

[kneitzel]

Java Code wird immer gleich übersetzt - mit javac.

Ob die dabei entstehenden .class Files auch eine oder mehr main Methoden enthält, ist dabei egal.

Zur Laufzeit müssen alle benötigten Klassen vorhanden sein. Dabei ist es egal, wie diese vorliegen, so lange diese vom ClassLoader geladen werden können. Üblich ist es dabei, das jar Dateien gebildet werden. Das sind aber enfach nur Archive, die vom ClassLoader gelesen werden können.

Eine Jar Datei kann neben den reinen Inhalten (class Files und Resources) aber auch noch zusätzliche Informationen enthalten:
- Manifest ist eine Datei mit zusätzlichen Informationen wie z.B. der Benennung einer main Class.
- Informationen zu Services.
- ...

Ausführbare Jar Datei besagt dann lediglich, dass ein Manifest vorhanden ist, das angibt, welche Klasse zu starten ist.

Hilft diese Aufgliederung etwas beim Verständnis weiter?

 

[von Spotz]

Hallo Kneitzel,

eigentlich war meine Kernfrage, was eine Library ist und wie genau man diese über die Kommandozeile erstellt bzw. einbindet.

Trotzdem Danke für Deine Ausführungen

Viele Grüße

 

[Hansen_07]

Eigentlich hat @kneitzel doch schon eine Menge erklärt und beschrieben.

Wenn du eine "Library", also eine .jar Datei erstellen möchtest, sieh dir das Tool jar an. Das ist bei jedem JDK dabei.

 

[Mart]

eigentlich war meine Kernfrage, was eine Library ist

ein haufen an klassen

und wie genau man diese über die Kommandozeile erstellt bzw. einbindet.

welche der gefühlt 10 verschiedenen Möglichkeiten willst du dir von jemand anders machen lassen
maven,gradle, ant, buildpath...

 

[von Spotz]

Danke Mart, fast so freundlich wie stackoverflow. Ich habe gesucht (!) und nichts gefunden. Also eine Library ist nur ein Paket in einem Jar Archiv? Ist eine Library ein ausführbares .jar Archiv oder wird es beim Kompilieren von Modulen über -cp eingebunden?

 

[von Spotz]

Und Entschuldigung, daß es Anfänger gibt, die das leider noch nicht alles wissen. Ich habe mittlerweile die meisten javac Optionen verinnerlicht. Trotzdem fehlt es mir noch an Beispielen. Nach guten Buchempfehlungen habe ich schon einmal gefragt. Ich gebe aber keine 50 EUR für ein Buchh aus, das meine Fragen gar nicht beantwortet, und mir gleich IntelliJ mit Gradle beibringen will. Ich habe meine Motivation extra auf Abstraktionen am Anfang zu verzichten jetzt schon mehrfach dargestellt und begründet.

 

[Mart]

eine Library ist gar nichts

eine Library ist eine Idee, eine Ansammlung von funktionen oder Klassen oder fertigen sachen die jemand nutzen kann


dann google "make maven repository " ein repository ist ansich eine Lib .. mehr oder weniger

 

[von Spotz]

Und Entschuldigung, daß es Anfänger gibt, die das leider noch nicht alles wissen. Ich habe mittlerweile die meisten javac Optionen verinnerlicht. Trotzdem fehlt es mir noch an Beispielen. Nach guten Buchempfehlungen habe ich schon einmal gefragt. Ich gebe aber keine 50 EUR für ein Buchh aus, das meine Fragen gar nicht beantwortet, und mir gleich IntelliJ mit Gradle beibringen will. Ich habe meine Motivation extra auf Abstraktionen am Anfang zu verzichten jetzt schon mehrfach dargestellt und begründet.

Ideal wäre ein Kochbuch das komplett auf IDEs verzichtet und sich nur mit der Kommandozeile beschäftigt!

 

[von Spotz]

eine Library ist gar nichts

eine Library ist eine Idee, eine Ansammlung von funktionen oder Klassen oder fertigen sachen die jemand nutzen kann


dann google "make maven repository " ein repository ist ansich eine Lib .. mehr oder weniger

Ist ein Paket wohl auch.

 

[Mart]

Ist ein Paket wohl auch.

exakt

 

[Mart]

Ideal wäre ein Kochbuch das komplett auf IDEs verzichtet und sich nur mit der Kommandozeile beschäftigt!

siehe maven

mvn install

fertig

glücklich ? wenn du den befehl zum laufen kriegst hast ein lokales repository die du dann von anderen projekten ( lokal ) importeiern kannst

 

[Mart]

das ist der einzige befehl den du brauchst... nicht alles ist fancy terminal wie in linux wo du

gcc -lstdc++ d.cpp

eintippst und dann noch 30 andere befehle um was zu kriegen

an der zeit ist man vorbei

 

[von Spotz]

Java Code wird immer gleich übersetzt - mit javac.

Ob die dabei entstehenden .class Files auch eine oder mehr main Methoden enthält, ist dabei egal.

Zur Laufzeit müssen alle benötigten Klassen vorhanden sein. Dabei ist es egal, wie diese vorliegen, so lange diese vom ClassLoader geladen werden können. Üblich ist es dabei, das jar Dateien gebildet werden. Das sind aber enfach nur Archive, die vom ClassLoader gelesen werden können.

Eine Jar Datei kann neben den reinen Inhalten (class Files und Resources) aber auch noch zusätzliche Informationen enthalten:
- Manifest ist eine Datei mit zusätzlichen Informationen wie z.B. der Benennung einer main Class.
- Informationen zu Services.
- ...

Ausführbare Jar Datei besagt dann lediglich, dass ein Manifest vorhanden ist, das angibt, welche Klasse zu starten ist.

Hilft diese Aufgliederung etwas beim Verständnis weiter?

Hallo Kneitzel, leider kann ich scheinbar keine private Konversation mit Dir beginnen (?)

 

[von Spotz]

das ist der einzige befehl den du brauchst... nicht alles ist fancy terminal wie in linux wo du

eintippst und dann noch 30 andere befehle um was zu kriegen

an der zeit ist man vorbei

Ich hatte in einem Tag ein funktionierendes makefile mit dem ich mein Cpp Projekt kompilieren konnte.

 

[Mart]

und warum willst du es dir selber bauen wenn es riesen projekte gibt die NUR das machen und da wesentlich viele profis dahinter stecken?


Diskussion zu starten bringt nichts, machs von mir aus mit dem javac und manage alles selber über den buildpath wie vor 20 jahren

PS die 20 ist willkürlich.. waren glaub ich weniger so 16 oder so

 

[kneitzel]

Hallo Kneitzel, leider kann ich scheinbar keine private Konversation mit Dir beginnen (?)

Ja, das ist deaktiviert ... und ich werde hier auch nicht mehr lange im Forum aktiv sein ... Ich schaue in erster Linie nur, ob der Account schon gelöscht wurde.

Aus meiner Sicht machst Du Dir zu sehr einen Kopf um die ganzen Java Kommandozeilen und was diese ganz im Detail machen. Das ist zwar auch alles dokumentiert aber nicht auf einem Level, der für Dich interessant und sinnvoll sein dürfte.

In der Praxis spielt es einfach keine Rolle. Viele Entwickler kennen ihr Projektmanagement Tool (wie z.B. Maven) und können da sehr viel konfigurieren, aber die Kommandozeilentools sind einfach egal und werden in der Tiefe nicht gekannt. Klar, die Möglichkeite sind wichtig und da muss man nach und nach erkennen, was es so alles gibt. Aber das ist etwas, das sich mit der Anwendung auch nach und nach ergibt.

Man kann aber natürlich auch alles von Grund auf erarbeiten. Aber da würde ich weniger auf die Tool-Ebene gehen. Da würde ich mich z.B. auf die Sprache selbst stürzen um diese im Detail zu verstehen. Da wäre die Java Language Specification der richtige Anlaufpunkt.
Die Java Virtual Machine Specification würde ich ebenso nicht behandeln (ohne triftigen Grund) wie die ganz genauen tiefen Details alles Tools. Statt dessen würde ich erst einmal Erfahrungen in der Praxis sammeln und schauen, was es da dann gibt.

Der nächste Schritt kann dann sein, dass man schaut: Was macht die IDE oder Maven oder ....? Sprich: schau Dir an, was da an Aufrufen genau statt findet. Dann kannst Du alles Schritt für Schritt nachvollziehen.

Gut erkannt hast Du: Da gibt es so kein wirkliches Buch zu. Das, was Dich da interessiert ist nicht wirklich für die breite Masse (so man diesen Begriff bei Software Entwicklern nutzen will) interessant. Ein Anlaufpunkt ist immer die Dokumentation (also beim Tool erst einmal ein -help). Und dann die Suche um da etwas zu finden, was aber schwer ist, denn es ist weit verteilt. Aber in vielen Blogs findet sich dazu einiges.

Daher auch der Tipp: Geh in die Praxis. Denn wenn Du mit offenen Augen durch die Welt gehst, dann findest Du gaz viele, interessante Quellen. Java Magazin von Oracle z.B. oder du schaust mal, wer so in der Entwicklung aktiv ist und suchst nach blog Beiträgen (Schwerer Weg - ich stolpere aber öfters mal über Beiträge bei denen ich dann feststelle, dass der auch mit Entwickelt ....) Was Du da aber findest ist mit dem aktuellen Wissenstand von Dir vermutlich noch nicht verständlich.... Aber das kommt.

Daher: Nicht unbedingt ein Thema erzwingen wollen. Das wird schwer und kostet viel Zeit und wird Dich vermutlich nicht wirklich weiter bringen.

Das ist aber natürlich nur meine Sicht. Da ich Dich im Detail nicht kenne, kann diese natürlich falsch sein. Daher auf keinen Fall irgendwas pers. nehmen sondern sieh es nur als das an, was es sein soll: Eine Information / Sicht von mir in der Hoffnung, dass diese dir etwas weiter hilft.

 

[mrBrown]

Ja, das ist deaktiviert ... und ich werde hier auch nicht mehr lange im Forum aktiv sein ... Ich schaue in erster Linie nur, ob der Account schon gelöscht wurde.

Kann man dich noch vom bleiben überzeugen?

 

[von Spotz]

Tja und ich habe immer noch keine klare Definition von "Java Library" bekommen.

 

[jari]

Ja, das ist deaktiviert ... und ich werde hier auch nicht mehr lange im Forum aktiv sein ... Ich schaue in erster Linie nur, ob der Account schon gelöscht wurde.

🙏 omg.

Nutze die freie Zeit sinnvoll. Ich begrüße diesen Schritt.

 

[temi]

Tja und ich habe immer noch keine klare Definition von "Java Library" bekommen.

Definitionen sind nicht einfach, wenn sie korrekt formuliert sein sollen. Eine Library ist eine Sammlung von Klassen, die andere Programme verwenden können.

 

[thecain]

Der Ausdruck Library ist in der Java Welt mMn auch gar nicht definiert. Klar verwenden ihn einige, aber das kann je nach Kontext oder Person etwas anderes bedeuten

 

[von Spotz]

Der Ausdruck Library ist in der Java Welt mMn auch gar nicht definiert. Klar verwenden ihn einige, aber das kann je nach Kontext oder Person etwas anderes bedeuten

Mein Lieber Herr Gesangsverein. Das klingt ja schon fast wie buddhistische Weisheiten. Oder Matrix: "Versuche nicht den Löffel zu verbiegen, sondern versuche die Wahrheit zu erkennen. Dann wirst du merken sehen dass nicht der Löffel sich biegt, sondern du selbst."

Java ist scheinbar die philosophischste Sprache die es gibt. \_(ツ)_/

 

[von Spotz]

Definitionen sind nicht einfach, wenn sie korrekt formuliert sein sollen. Eine Library ist eine Sammlung von Klassen, die andere Programme verwenden können.

Und ohne den Dubislav (Standardwerk der Definitionslehre. Bis heute. https://www.amazon.de/Die-Definition-Walter-Dubislav/dp/3787305130) auszupacken kann man das echt nicht definieren. Ok, dann bitte ich um etwas anderes. Eine Begriffs-Explikation. Eine Explikation fordert weniger als eine Definition (von der Definition als Festsetzung einmal abgesehen)
[/polemik]

An Beispielen zum Packen in .jar Dateien über die Kommandozeile mittels jar findet man viel Material. Daran hapert es nicht! Ich werde im nächsten Post einfach beschreiben, wie ein standalone / executable jar erzeugt wird und darauf basierend kann ich konkreter fragen, was an dem Procedere geändert werden muss, um nicht eine executable jar sondern eine library als jar verpackt zu erhalten, die eben nicht ausführbar sein soll. Ich bitte nur darum, ausschlafen zu dürfen und dieses in ein paar Stunden nachzuliefern.

Danke für eure Antworten und bis bald!

Euer
vonSpotz

 

[mihe7]

Ja, das ist deaktiviert ... und ich werde hier auch nicht mehr lange im Forum aktiv sein ... Ich schaue in erster Linie nur, ob der Account schon gelöscht wurde.

WTF?!? Was ist passiert?

 

[kneitzel]

was an dem Procedere geändert werden muss, um nicht eine executable jar sondern eine library als jar verpackt zu erhalten, die eben nicht ausführbar sein soll.

Eine Library schliesst nicht aus, dass diese auh usgeführt werden kann. Beispiel Project Lombok: Da hat man eine Libraray, die in den Compilelauf eingreifen kann aber zugleich kann man die jar auch ausführen (Stichwort "DeLombok").

Wenn Du eine reine Library haben willst, dann wirst Du keine main Class haben und somit wird der Eintrag im Manifest schlicht nicht vorhanden sein.

 

[temi]

Was ist eigentlich das Problem? Ich verstehe wirklich nicht, warum du dir da so einen Kopf machst.

public class MyMath {
 
    public double add(double a, double b) {
        return a + b;
    }
}

Übersetzt das und schon hast du deine (zugegeben sehr einfache) Mathe-Library. In irgend einem deiner anderen Programme kannst du dieses jar dann mittels Import verwenden (natürlich nachdem du die entstandene jar diesem Programm hinzugefügt hast).

EDIT: Eine aufwändigere Bibliothek würde man allerdings eher in ein Maven-Repository veröffentlichen, um sie später ebenfalls per Maven/Gradle einfacher verwenden zu können.

EDIT: Mir ist grade eingefallen, meinst du vielleicht dynamische Bibliotheken, also DLLs (Windows)?

 

[LimDul]

Eine Library ist erstmal nicht mehr als meistens ein, manchmal auch mehrere, Jar-Dateien, die kompilierten Java-Code enthalten. Die Jar-Files kann man in seine Anwendung einbinden und kann dann die Java-Klassen nutzen.

Ob das Jar ausführbar ist oder nicht, ist dafür vollkommen unerheblich. In der Regel ist es das nicht, weil es selten einen Grund gibt, aber wie @kneitzel schon schrieb gibt es auch Fälle wo es ausführbar ist.

In der Regel - wie @temi schrieb - werden die meisten größeren Bibliotheken über Maven-Repositories veröffentlicht. Das erleichtert die Nutzung dieser Bibliotheken enorm, da man sie über maven einfach einbinden kann und keinen Stress hat sich alle benötigten Jar-Dateien zusammen zu suchen, das übernimmt Maven für einen.

 

[temi]

In der Regel - wie @temi schrieb - werden die meisten größeren Bibliotheken über Maven-Repositories veröffentlicht. Das erleichtert die Nutzung dieser Bibliotheken enorm, da man sie über maven einfach einbinden kann und keinen Stress hat sich alle benötigten Jar-Dateien zusammen zu suchen, das übernimmt Maven für einen.

Vor allem, weil viele Bibliotheken auch wieder andere Bibliotheken verwenden.

 

[Gelöschtes Mitglied 65838]

Eine Library schliesst nicht aus, dass diese auh usgeführt werden kann.

weiteres beispiel wäre bibliotheken die beispiele für eine Andere bibliothek enthalten die du starten kannst