Fachrat Informatik - Forum

Quoted

Original von Nadja
Was ist jetzt mit .jar ?????

Wie kann man aus eine Datei mit der Endung .java eine Datei mit der Endung .jar erstellen..

Du möchtest also wissen, wie man JAR-Pakete erstellt?

Falls ja: http://www.google.de/search?q=jar+erstellen hilft hier weiter, unter anderem findet man dort Verweise auf http://wiklet.javacore.de/index.php/Jar_…baren_Jar-Datei und http://java.sun.com/docs/books/tutorial/deployment/jar/.

Hilft Dir das weiter?

Ein JAR ist eine Art Zip-Archiv, dass alle deine Dateien zusammenfasst.

Quoted

JAR files are packaged with the ZIP file format, so you can use them for "ZIP-like" tasks such as lossless data compression, archiving, decompression, and archive unpacking. These are among the most common uses of JAR files, and you can realize many JAR file benefits using only these basic features.

[...]

To perform basic tasks with JAR files, you use the JavaTM Archive Tool provided as part of the Java Development Kit. Because the Java Archive tool is invoked by using the jar command, for convenience we'll call it the "Jar tool".

Ein Jar erstellst du mit dem Befehl

Quoted

The basic format of the command for creating a JAR file is:

jar cf jar-file input-file(s)

Let's look at the options and arguments used in this command:

* The c option indicates that you want to create a JAR file.
* The f option indicates that you want the output to go to a file rather than to stdout.
* jar-file is the name that you want the resulting JAR file to have. You can use any filename for a JAR file. By convention, JAR filenames are given a .jar extension, though this is not required.
* The input-file(s) argument is a space-separated list of one or more files that you want to be placed in your JAR file. The input-file(s) argument can contain the wildcard * symbol. If any of the "input-files" are directories, the contents of those directories are added to the JAR archive recursively.

The c and f options can appear in either order, but there must not be any space between them.

This command will generate a compressed JAR file and place it in the current directory. The command will also generate a default manifest file (in the Deployment trail) for the JAR archive.

Alle Zitate sind von http://java.sun.com/docs/books/tutorial/…asicsindex.html , wo es sehr ausführlich erklärt wird.

Also, vereinfacht erklärt:

Jede Java-Applikation hat ein Wurzelverzeichnis (Root). Das ist sozusagen die Basis des ganzen. Bezeichne ich hier als "/". Man könnte auch sagen es handelt sich bei diesem Verzeichnis um das namenlose default-Package.

.java-Dateien enthalten eine oder mehrere Java-Klassen. Jede .java-Datei muss am Anfang der Datei eine einzige package-Deklaration enthalten: package soundso;. Das Package entspricht dem Pfad vom Root aus. Also z.B. bei folgender Verzeichnisstruktur:

/
/foo
/foo/X.java
/foo/bar
/foo/bar/Y.java

enthält X.java die Deklaration "package foo;" und Y.java die Deklaration "package foo.bar;".

Nun möchte man in seinen Klassen natürlich andere Klassen benutzen. Wenn die sich im gleichen Package (=Verzeichnis) befinden, braucht man keine import-Anweisung. Wenn sie das NICHT tun, braucht man eine. Entweder man import das ganze Package, in dem auch die Klasse liegt die man braucht, oder nur die Klasse. Wenn man z.B. in Y.java auf die Klasse foo.X zugreifen will, benötigt Y.java die Anweisung

"import foo.*;"

oder

"import foo.X;".

Nun gehts ans kompilieren. Kompiliert wird am besten aus dem Root-Verzeichnis der Anwendung und zwar alles auf einmal. Also begibt man sich ins Verzeichnis "/" und gibt dort ein:

javac foo/X.java bar/Y.java

Es entstehen .class files jeweils in den richtigen Paketen. Für den Aufruf muss die Engine den CLASSPATH kennen, eine Liste von Roots von Java-Anwendungen. Aufruf des ganzen dann, wenn main() in X:

java -cp . foo.X;

Zum Abschluss kann man das ganze nun noch in ein JAR packen, wenn man mag. Ein JAR enthält genau die Verzeichnisstruktur, wie man sie eh schon hat (+ noch ein bisschen meta-info). Also in "/" wieder aufrufen:

jar -cf meinjar.jar *

Dann kann man auch das Jar zum Aufruf verwenden:

java -cp meinjar.jar foo.X;

Abschließende Worte: Weil das ganze auf Kommandozeile extrem nervt nehme man sich Eclipse: http://www.eclipse.org/

Eclipse kann ALLES!

Im Ernst, natürlich. Packages und JAR files sind so ziemlich das einfachste am Funktionsumfang einer Java-IDE.

Eclipse ist allerdings natürlich auch selbst ein komplexes Paket. Das brauchst selbst auch wieder Einarbeitungszeit...

Da deine Fragen jedoch relativ grundlegend sind, würde würde ich mir an deiner Stelle ein gutes Buch zu Java holen, und eins zu Eclipse, oder vielleicht eins, in dem beides gleichzeitig erklärt wird. Das ist sicher am einfachsten. Vielleicht kann ja jemand eins empfehlen.

Man verzeihe mir, wenn ich etwas ungehalten bin, aber ich habe gestern 5+ Stunden gebraucht, um mehrere Fehler/Ungenauigkeiten, etc zu fnden und bei allen die richtige Lösung anzuwenden -.-

Zum Ersten darf man auf keinen Fall vergessen, im Manifest-Eintrag "Main-Class" auch die package-Struktur mit abzubilden ....Es hat wirklich lange gedauert, die info zu finden .... und nein, ich finde sie zwar logisch, aber kein Tick intuitiv

Zum Zweiten ist es ääächt intelligent, die Information über die "trailing newline" in eine FUSS-Note zu schreiben .... da gehören vielleicht schlechte Witze des Autors oder weiterführende Literaturhinweise oder sonst irgendwas hin, aber doch keine Information, die für den Ablauf des Ganzen unabdingbar ist. Mag man dem Dozenten nicht anlasten, dass er kein eigenes Skript geschrieben hat, kann man wohl trotzdem geltend machen, dass er ein vernünftiges hätte raussuchen sollen. Und ja, ich weiß, dass es Literatur, auch online und google gibt .... aber wer vermutet denn bitte den Fehler in einem fehlenden linebreak?

Drittens muss man bei dieser Paketstruktur auch in den übergeordneten Ordner wechseln, bevor man das ganze packt.

Das gilt nebenbei auch fürs Kompilieren! Und die Information hab ich tatsächlich noch nirgendwo gefunden. Und auch die Fehlermeldungen von Java helfen einem kein bisschen weiter, man sucht an den total falschen Stellen:Anhand dieser Fehlermeldung nimmt doch jeder normal denkende Mensch an, dass die Klassendefinition irgendwie nicht in Ordnung ist .... statt einen Ordner hoch zu gehen, von dort zu kompilieren und auszuführen .... erheblich sinnvoller wäre eine Meldung gewesen wie "wrong name: Simulation, expected fruehlingssimulation/Simulation" ... den Stacktrace hätten die sich an der Stelle echt sparen können -.-

Dann is das Geheule um den CLASSPATH an sich doch Quatsch, schließlich sucht Java schon von sich aus zuerst mal in dem Ordner, in dem man sich befindet ... sonst müsste man ja jedesmal, wenn man eine andere .class-Datei ausführen will, die Shell-Variablen ändern :O ... oder?
Außerdem gibt es für das Manifest die Option "Class-Path" ... http://java.sun.com/docs/books/tutorial/…ar/downman.html (Danke für den Link btw.)

Vielleicht helfen die Hinweise

Mata ne
Warui